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ABSTRACT 


Adversaries  scan  Department  of  Defense  networks  looking  for  vulnerabilities  that  allow  surveil¬ 
lance  or  the  embedding  of  destructive  malware  weapons.  In  cyberspace,  adversaries  either  ac¬ 
tively  probe  or  passively  observe  defended  computer  networks  in  attempts  to  determine,  among 
other  attributes,  the  topology  of  the  network.  We  develop  a  novel  strategic  deceptive  method¬ 
ology,  based  on  principles  of  military  deception,  for  deceiving  a  malicious  traceroute  probe  in 
defense  of  a  physical  data  communications  network.  We  construct  a  proof-of-concept  network 
to  show  that  a  remote  adversary  who  uses  traceroute  to  map  the  defended  network’s  topology 
can  be  presented  with  a  false  route  of  the  defender’s  choosing.  Akin  to  military  deception  op¬ 
erations  in  the  field  and  at  sea,  a  network  that  employs  a  deception  scheme  implemented  on 
an  intelligent  border  router  can  present  a  deceptive  topology  to  an  adversary.  Our  experiments 
show  that  a  defender  using  our  technique  can  successfully  deceive  a  traceroute  probe,  the  first 
in  a  sequence  of  steps  to  mount  a  credible  deception  scheme  against  an  adversary. 
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CHAPTER  1: 
INTRODUCTION 


In  this  chapter  we  discuss  the  applicability  of  the  research  contained  herein  to  the  Department 
of  Defense  (DoD)  and  the  pervasiveness  of  the  threat  of  computer  network  probing  as  well  as 
offer  a  technique  based  on  deception  for  countering  the  threat. 

1.1  Application  to  the  Department  of  Defense 

Cyber  warfare  is  moving  to  a  more  central  position  in  U.S.  national  security  concerns.  The  2010 
National  Security  Strategy  (NSS),  Quadrennial  Defense  Review  (QDR),  and  the  2011  DoD 
Strategy  for  Operating  in  Cyberspace  each  place  greater  emphasis  on  defending  cyberspace 
than  in  the  past.  In  a  2012  speech  given  to  the  Business  Executives  for  National  Security  in 
New  York,  Defense  Secretary  Leon  Panetta  warned  of  an  impending  “cyber  Pearl  Harbor;  an 
attack  that  would  cause  physical  destruction  and  the  loss  of  life.  In  fact,  it  would  paralyze  and 
shock  the  nation  and  create  a  new,  profound  sense  of  vulnerability.  [1]”  As  the  importance  of 
cyberspace  as  a  war-fighting  domain  grows,  so  will  the  need  for  a  robust  toolkit  of  cyber  war¬ 
fighting  techniques.  The  research  presented  herein  offers  a  novel  technique  that  may  be  added 
to  the  suite  of  tools  available  to  defend  DoD  networks. 

1.2  Pervasive  Network  Probing 

In  cyberspace,  adversaries  either  actively  probe  or  passively  observe  defended  computer  net¬ 
works  in  attempts  to  determine,  among  other  attributes,  the  topology  of  the  network.  Both  DoD 
and  corporate  networks  alike,  in  the  U.S.  and  around  the  world,  are  probed  thousands  of  times 
a  day  for  vulnerabilities  and  points  of  access  [2] . 

The  intuitive  response  to  such  near-constant  probing  may  be  to  selectively  deny  the  adversary’s 
probes  from  entering  the  network  while  allowing  all  other  traffic  to  pass.  Unfortunately,  it  is 
hard  to  distinguish  legitimate  traffic  from  malicious  probes,  and  it  is  nearly  impossible  to  know 
with  certainty  that  an  adversary  is  successfully  blocked  from  probing  a  defended  network. 

1.3  Military  Deception  in  Cyberspace 

Instead  of  merely  denying  the  adversary  a  vantage  into  a  defended  network,  this  thesis  examines 
if  there  is  value  to  be  gained  in  employing  the  principle  of  military  deception  by  presenting  a 
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false  network.  Such  deception  can  frustrate  an  adversary’s  ability  to  gain  usable  intelligence 
from  a  target  and  thus  prevent  exploitation  of  the  network. 

The  use  of  military  deception  in  warfare  dates  back  to  ancient  times.  The  most  well-known 
example  is  that  of  the  Trojan  Horse,  a  ruse  the  Greeks  used  to  infiltrate  and  sack  the  city  of 
Troy  during  12th  century  BC.  Today,  deception  tactics  abound,  including  placement  of  inflat¬ 
able  mock-ups  of  tanks,  airplanes  made  of  wood,  warships  with  lighting  rigged  to  appear  as 
merchant  vessels,  and  intentional  disclosure  of  false  intelligence  that  purports  to  reveal  upcom¬ 
ing  operations.  In  the  field  of  electronic  warfare  (EW),  radar  systems  are  capable  of  jamming 
an  adversary’s  signal  or  subtly  modifying  its  return  so  as  to  alter  the  perceived  distance  to  its 
target. 

Military  deception  is  one  of  the  pillars  of  information  operations  (10)  and  has  long  been  used  as 
a  viable  and  valuable  military  tactic  at  sea,  on  land  and  in  the  air.  Joint  Publication  (JP)  3-13.4 
defines  military  deception  (MILDEC)  as: 


Those  actions  executed  to  deliberately  mislead  adversary  decision  makers  as  to 
friendly  military  capabilities,  intentions,  and  operations,  thereby  causing  the  adver¬ 
sary  to  take  specific  actions  (or  inactions)  that  will  contribute  to  the  accomplishment 
of  the  friendly  mission.  [3] 


It  is  reasonable,  therefore,  to  expect  value  in  deceiving  adversaries  within  the  confines  of  cy¬ 
berspace.  To  that  end,  we  explore  the  use  of  deception  in  the  cyber  domain.  We  present  here 
a  novel  technique  for  topological  deception  in  which  an  adversary  is  presented  with  a  false 
network  topology  that  purposefully  conceals  and  disguises  the  underlying  true  topology. 

This  thesis  focuses  on  adversaries  that  are  performing  active  probing.  Active  probing  tools 
available  to  the  adversary  include  traceroute,  ping  sweeps,  and  port  scanners.  A  discussion  of 
these  tools  is  offered  in  §  2.2.  These  tools  produce  a  wide  range  of  effects  that  are  advantageous 
to  the  adversary.  The  intelligence  gained  from  such  probing  allows  an  attacker  to  gain  valuable 
insight  into  which  nodes  in  the  network  would,  if  disabled  by  attack,  yield  the  greatest  overall 
impact  (e.g.,  network  disruption,  or  other  objective).  In  particular,  this  research  is  concerned 
with  the  effect  of  attacks  on  “weak”  nodes  within  the  topology  that  might  partition  the  network. 
A  network  is  partitioned  when  a  high-value  node  is  disabled  causing  significant  segments  of  a 
network  to  lose  connection. 
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In  order  to  prevent  a  partitioning  attack,  we  offer  a  defense  based  on  the  principle  of  deception 
in  which  the  outward  appearance  of  a  network  topology  is  altered  and  presented  to  an  attacker 
for  the  purpose  of  protecting  high-value  nodes  or  links  within  the  network.  Thus  we  may  cause 
the  adversary  to  take  specific  actions,  such  as  attacking  highly  fault-tolerant  nodes  that  appear 
weak,  or  avoiding  weak  nodes  that  appear  highly  fault-tolerant. 

It  is  possible  to  present  a  deceptive  network  topology  through  the  careful  manipulation  of  the 
responses  to  an  adversary’s  probes.  This  thesis  proposes  a  novel  deception  methodology,  then 
demonstrates  the  feasibility  of  presenting  a  deceptive  network  topology  to  an  adversary.  The 
deception  is  implemented  via  the  manipulation  of  outbound  traffic  for  the  purpose  of  deceiving 
a  traceroute  scan. 

An  outer  layer  of  defense  in  the  form  of  an  intelligent  router,  one  that  is  capable  of  identify¬ 
ing  traceroute  scans  and  providing  a  deceptive  route  in  reply,  may  thwart  an  adversary’s  efforts 
to  subvert  critical  nodes  and  links  in  defended  networks.  The  intelligent  router  presents  the 
deceptive  route  while  allowing  all  other  traffic  into  the  network.  Such  an  approach  subverts  a 
traceroute  scan  while  allowing  other  forms  of  traffic  to  flow  in  and  out  of  the  network  unim¬ 
peded.  Our  research  proceeds  in  this  direction. 

By  developing  a  proof-of-concept  network,  we  demonstrate  a  strategic  deceptive  methodology 
for  deceiving  a  malicious  traceroute  scan  in  defense  of  a  physical  data  communications  net¬ 
work.  Akin  to  military  deception  operations  in  the  field  and  at  sea,  the  deception  will  present 
adversaries  running  traceroute  with  a  deceptive  route  to  a  protected  target.  The  deceptive  route 
is  constructed  such  that  it  causes  the  adversary  to  incorrectly  ascertain  the  relative  position  (and 
therefore,  the  value)  of  a  node  in  a  network.  The  methodology  accommodates  any  true  input 
topology,  while  the  deceptive  topology  can  be  modified  easily  and  frequently  if  necessary  to 
further  confound  the  adversary’s  efforts  to  identify  vulnerabilities  in  the  physical  network. 

By  influencing  the  adversary’s  decision-making,  he  can  be  lured  into  a  course  of  action  that 
is  favorable  to  the  defender’s  objectives.  The  methodology  proposed  here  could  potentially  be 
used  to  entrap  adversary  attacks,  which  would  then  permit  forensic  analysis  and  defense  against 
similar  attacks  in  the  future.  Furthermore,  due  to  the  highly  flexible  nature  of  the  implementa¬ 
tion,  an  adversary  may  be  kept  longer  in  an  intelligence  collection  phase  of  their  mission  while 
attempting  to  pin  down  the  exact  topology  of  a  network.  From  the  adversary’s  perspective, 
the  topology  may  appear  substantially  more  complex  than  its  true  structure,  or  may  be  made 
to  appear  as  though  it  is  continually  and  unpredictably  changing.  This  prolonged  stay  in  an 
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intelligence  collection  phase  may  prevent  the  adversary  from  transitioning  to  an  operational 
phase. 

This  thesis  demonstrates  how  a  physical  network  may  be  disguised  by  an  intelligent  router  ca¬ 
pable  of  manipulating  outbound  traffic.  The  manipulated  traffic  may  provide  the  perception  of  a 
network  that  resembles,  or  completely  disguises,  the  underlying  physical  network  while  having 
the  ability  to  easily  vary  any  attribute  of  the  network,  such  as  node  count  or  the  redundancy  of 
links  between  vital  nodes.  The  work  described  herein  has  not  been  deployed  on  a  production 
network,  nor  has  the  method  been  tested  against  human  participants.  However,  we  introduce 
a  working  implementation  of  deception  in  a  Linux  kernel  module  executing  as  an  intelligent 
router.  The  execution  of  the  kernel  module  is  shown  to  work  within  a  synthetic  network  topol¬ 
ogy  with  an  adversary  probing  the  path  to  a  publicly  available  service  (a  web  server)  whereby 
the  attacker  infers  the  deceptive  (false)  route.  The  resilience  of  the  deceptive  network  presented 
to  the  adversary  may  be  compared,  for  instance  using  graph  theoretic  measures,  against  the  true 
physical  topology.  Such  comparisons  are  left  to  future  work. 

The  remainder  of  this  thesis  is  organized  as  follows.  In  Chapter  2,  we  explore  the  background 
of  cyber  deception  and  present  a  representative  sample  of  literature  on  the  topic.  In  Chapter  3, 
we  discuss  the  details  of  the  topological  deception  implemented  herein.  In  Chapter  4,  we  share 
the  findings  of  our  experiments.  Our  conclusion  in  presented  in  Chapter  5. 
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CHAPTER  2: 

BACKGROUND  AND  REVIEW  OF  LITERATURE 


Deception  in  cyberspace  is  not  a  new  practice  and  many  researchers  have  examined  the  various 
aspects  of  cyber  deception  employed  by  attackers  and  defenders.  Before  reviewing  a  repre¬ 
sentative  sample  of  the  body  of  work  that  explores  deception  in  the  physical  domain  and  in 
cyberspace,  we  first  explore  some  of  the  tools  used  for  cyber  denial  and  deception.  We  begin 
this  chapter  with  an  explanation  of  the  workings  of  the  traceroute  program. 

2.1  Traceroute  Basics 

Before  describing  traceroute,  we  take  a  moment  to  describe  network  ports,  User  Datagram 
Protocol  (UDP)  and  Internet  Control  Message  Protocol  (ICMP). 

2.1.1  Ports 

In  computer  networking,  ports  are  used  as  a  method  of  permitting  multiple  services  (software) 
access  to  a  single  network  interface  without  interfering  with  each  other.  Ports  are  defined  by 
a  16-bit  number  and  are  concatenated  to  an  Internet  Protocol  (IP)  address  thus  providing  a 
complete  address  to  a  service  on  a  computer.  A  port  that  is  bound  to  a  running  service  is  said  to 
be  “open.” 

2.1.2  User  Datagram  Protocol 

UDP  is  a  component  of  the  IP  suite.  UDP  is  designed  to  be  fast  by  imposing  a  minimum  of 
protocol  overhead.  UDP  packets  are  prefixed  with  an  IP  header  containing  the  source  address, 
destination  address,  and  a  time  to  live  (TTL)  field.  UDP  is  fast  because  it  sacrifices  elements 
available  in  Transmission  Control  Protocol  (TCP)  such  as  ordered  delivery  of  packets,  delivery 
confirmation  and  duplication  avoidance  [4].  Of  note,  some  traceroute  implementations  use  TCP 
packets  since  they  are  able  to  pass  through  firewalls  which  are  typically  configured  to  allow 
TCP. 

Relevant  to  this  research,  the  header  of  a  UDP  packet  contains,  among  others,  fields  for  the 
source  port  and  destination  port.  The  destination  port  of  a  UDP  packet  may  be  any  16-bit  value. 
Traceroute,  by  historical  convention,  uses  the  port  range  of  33434  to  33534  when  sending  UDP 
packets  to  a  destination.  Traceroute  uses  a  range  of  ports  rather  than  a  single  port  to  allow  for 
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multiple  simultaneous  executions  of  traceroute  on  a  single  host  with  replies  being  matched  to 
the  original  execution. 

2.1.3  Internet  Control  Message  Protocol 

ICMP  was  designed  to  support  datagram  error  reporting  between  hosts  [5].  ICMP  messages 
are  described  by  various  types  with  each  type  reporting  to  the  recipient  the  type  of  error  that 
occurred. 

Programmers  such  as  Muuss  [6]  employed  ICMP  to  develop  some  of  the  earliest  TCP/IP  prob¬ 
ing  tools.  One  simple  type  of  probe  uses  the  Ping  command  to  systematically  scan  for  IP 
addresses  in  use.  The  Ping  command  sends  out  an  ICMP  echo  request  to  a  specified  host  and 
waits  for  echo  reply  messages.  In  cases  where  ICMP  traffic  is  not  blocked  by  a  firewall  or  ig¬ 
nored  by  the  destination  host.  Ping  is  able  to  determine  if  a  host  or  IP  address  is  up  and  active 
on  a  network  [7]. 

2.1.4  Traceroute 

Traceroute  is  a  network  diagnostic  tool  for  reporting  nodes  in  a  path  to  a  destination  and  the 
delay  times  associated  with  each  node.  Nodes  are  typically  routers  and  may  also  be  computers 
configured  to  act  as  routers.  Traceroute  reports  only  the  forward  path  in  a  route.  For  routers, 
which  have  multiple  network  interfaces,  the  forward  path  means  that  only  the  interface  nearest 
the  prober  is  reported  by  a  traceroute  probe.  UDP  is  the  default  packet  transmission  method 
used  by  traceroute  on  the  Linux  operating  system  (OS)  (the  tracert  program  for  the  Windows 
OS  uses  ICMP  by  default).  The  research  presented  in  this  thesis  focuses  on  traceroute’s  use  of 
UDP  only. 

A  typical  traceroute  command  takes  a  form  such  as: 


#  traceroute  192.168.5.2 


The  result  this  command  generates  is  shown  in  Figure  2.1.  The  first  column  is  an  incrementing 
count  of  nodes  discovered  between  the  prober  and  the  destination.  The  IP  address  for  each 
discovered  node  is  shown  in  the  second  column.  By  default,  traceroute  sends  UDP  packets  in 
groups  of  three  meaning  that  for  each  TTL  value,  three  probes  are  sent.  The  next  three  columns 
show  the  round-trip  time  taken  for  each  probe.  The  round-trip  time  is  the  time  between  sending 
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traceroute  to 

1  192.168.9. 

2  192.168.0. 

3  192.168.1. 

4  192.168.2. 

5  192.168.3. 

6  192.168.4. 

7  192.168.5. 


192.168.5.2  (192 

1  (192.168.9.1) 

2  (192.168.0.2) 

2  (192.168.1.2) 

2  (192.168.2.2) 

2  (192.168.3.2) 

2  (192.168.4.2) 

2  (192.168.5.2) 


168 .5.2) , 
2.859  ms 
9.673  ms 
16.250  ms 
21.723  ms 
31.812  ms 
43.832  ms 
22.655  ms 


30  hops  max,  60  byte  packets 
5.490  ms  7.707  ms 
11.539  ms  14.296  ms 
18.176  ms  20.255  ms 
23.669  ms  25.591  ms 
33.677  ms  35.675  ms 
18.201  ms  18.853  ms 
24.371  ms  26.258  ms 


Figure  2.1:  An  example  of  traceroute  output. 


the  UDP  packet  to  receiving  the  matching  ICMP  Time  Exceeded  message. 

To  understand  how  traceroute  finds  this  route  we  look  to  its  control  of  the  TTL  field  and  its  use 
of  UDP  and  ICMP.  The  TTL  field  is  controlled  by  traceroute,  with  the  first  packet  in  a  probe 
having  TTL=1.  For  each  UDP  packet  sent  during  a  probe,  traceroute  expects  an  ICMP  Time 
Exceeded  packet  in  reply  (or  a  Port  Unreachable  message  when  the  destination  is  reached). 
Traceroute  prepares  a  UDP  packet  for  delivery  for  the  first  group  of  three  packets  in  a  probe. 
In  our  example,  the  destination  address  for  every  packet  in  the  probe  is  192.168.5.2.  The  TTL 
of  the  first  packet  is  set  to  one.  After  the  probing  computer  sends  out  the  packet,  it  arrives 
at  the  next  nearest  node  (192.168.0.2)  along  the  route  to  the  destination.  The  receiving  node 
decrements  the  TTL.  For  the  first  packet,  the  action  sets  the  TTL  to  zero,  thus  causing  the 
packet  to  expire.  The  node  will  not  allow  the  expired  message  to  continue  on  and  generates 
an  ICMP  error  message  of  type  Time  Exceeded  and  sends  it  back  to  the  prober.  Recall,  that 
the  default  operation  of  traceroute  is  to  send  UDP  packets  in  groups  of  three  thus  the  first  three 
packets  in  the  probe  have  TTL=1  and  192.168.0.2  responds  to  all  three  in  identical  manner. 

The  second  group  leaves  the  probing  host  with  TTL=2.  The  next  node  decrements  the  TTL  of 
each  node  as  before,  however,  the  TTL  has  not  yet  expired  so  the  node  forwards  the  packet.  In 
our  example,  192.168.1.2  receives  the  next  group  of  three  packets.  This  node,  like  the  one  before 
it,  decrements  TTL  and  replies  to  the  prober  with  the  ICMP  Time  Exceeded  error  message.  This 
process  continues  until  a  group  of  three  packets  finally  arrives  at  the  destination  (192.168.5.2). 

The  destination  computer,  upon  receiving  the  packets,  attempts  to  deliver  them  to  the  port  re¬ 
quested  by  the  prober.  Recall  that  traceroute  uses  ports  in  the  range  of  33434  to  33534  which  is 
a  registered  range  as  specified  by  Internet  Assigned  Numbers  Authority  (LANA).  Reserving  the 
port  range  for  traceroute  implies  that  no  other  service  should  use  this  range.  Assuming  no  other 
service  is  running  in  this  range,  when  traceroute  attempts  an  access  in  this  range  on  the  desti- 
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nation  computer,  the  destination  computer  is  obliged  to  reply  with  an  ICMP  Port  Unreachable 
message.  When  the  Port  Unreachable  message  is  received  by  the  prober,  the  probe  is  ceased 
and  traceroute  exits  execution. 


2.2  Tools 

In  addition  to  traceroute,  there  are  two  other  primary  tools  used  by  an  adversary  to  gain  intel¬ 
ligence  on  a  target  network.  Those  tools  are  ping  sweeps,  and  port  scanners.  Here  we  discuss 
how  an  adversary  uses  these  three  tools  and  the  defender’s  countermeasures  against  them. 

2.2.1  Ping  Sweeps 

The  standard  Ping  implementation  limits  its  user  to  ping  only  one  host  at  a  time.  For  an  ad¬ 
versary,  it  is  very  time  consuming  to  probe  only  one  host  at  a  time.  There  are  workarounds  to 
this  limitation  such  as  wrapping  the  Ping  program  in  a  shell  or  batch  script.  Doing  so  enables 
many  hosts,  even  entire  subnets,  to  be  quickly  probed  and  thereby  provide  the  adversary  with 
a  better  understanding  of  the  available  attack  surface.  Better  yet,  improved  implementations  of 
Ping  exist. 

Fping  [8],  which  stands  for  “fast  pinger,”  solves  the  limitation  of  being  able  to  ping  only  one 
host  at  a  time.  By  taking  a  list  of  IP  addresses,  either  from  standard  input  or  in  a  flat  text  file, 
Fping  is  able  to  scan  entire  networks  much  faster  than  would  be  possible  with  the  standard  Ping 
utility  [7].  Using  the  results  of  an  Fping  probe,  an  adversary  may  develop  a  list  of  potential 
target  hosts  on  a  network. 

The  standard  Ping  program  is  limited  not  only  by  its  ability  to  ping  one  host  at  a  time  but  also 
in  that  it  sends  pings  using  ICMP  only.  Routers  may  be  configured  to  block  ICMP  traffic,  and 
hosts  may  be  configured  to  ignore  ICMP.  The  Hping  [9]  program  avoids  such  a  limitation  by 
eliciting  the  same  behavior  from  a  target  host  that  an  ICMP  ping  would  cause  by  using  UDP 
packets  or  TCP  instead.  It  does,  however,  support  ICMP  as  well. 

2.2.2  Port  Scanning 

Port  scanning  involves  probing  a  host  for  open  ports.  Its  use  is  described  by  Request  For 
Comment  (RFC)  4949,  “A  port  scan  can  be  used  for  pre-attack  surveillance,  with  the  goal 
of  finding  an  active  port  and  subsequently  exploiting  a  known  vulnerability  of  that  port’s  ser¬ 
vice.  [10]” 
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Nmap  [11]  is  the  most  commonly  used  port  scanner  today.  Like  Hping,  it  bypasses  Ping’s 
limitation  of  using  only  ICMP  by  using  UDP  and  TCP.  Nmap  is  a  robust  program  that  not  only 
determines  whether  a  host  exists  at  an  IP  address  but  also  which  ports,  and  therefore  which 
services,  are  available  on  that  host  [7]. 

2.2.3  Topology  Mapping  via  Traceroute 

Traceroute  is  one  of  many  tools  used  to  infer  topology,  but  doing  so  is  no  trivial  task.  Traceroute 
sends  probes  using  UDP  and  relies  on  ICMP  replies  to  gather  information  regarding  the  route 
between  the  prober  and  the  destination.  A  traceroute  scan  receives  two  types  of  ICMP  mes¬ 
sages:  Time  Exceeded  and  Destination  Unreachable.  There  are  six  sub-types  of  a  Destination 
Unreachable  Message.  In  particular,  traceroute  receives  the  Port  Unreachable  sub-type. 

Traceroute,  used  alone  or  in  concert  with  other  tools,  is  not  a  fool-proof  method  of  mapping  a 
target  network.  Intentional  and  unintentional  outside  factors  may  affect  the  results  obtained  in 
a  traceroute  probe.  Routers  may  be  configured  to  block  UDP  traffic  thus  thwarting  a  traceroute 
probe.  Routers  may  also  be  configured  to  prohibit  sending  ICMP  messages  which  may  also 
thwart  a  probe.  Furthermore,  network  congestion,  queuing,  network  maintenance  and  other 
conditions  may  affect  the  results  provided  by  a  traceroute  probe. 

There  has  been  significant  work  in  inferring  Internet  topologies.  However,  because  of  the  Inter¬ 
net  architecture,  doing  so  is  fundamentally  difficult  and  the  use  of  inference  processes  introduce 
errors.  These  errors  can  include  false  links,  missing  links,  etc.  Willinger  el  al.  [12]  show  the 
ease  with  which  such  mistakes  can  be  made.  We  turn  this  to  our  advantage  by  exploiting  the 
ease  to  which  an  adversary  attempting  to  map  the  network  may  be  deceived. 

2.2.4  Firewalls 

Firewalls  are  the  de  facto  standard  for  denial  of  network  access  to  adversaries.  Oppliger  [13] 
describes  the  operation  of  firewalls  best  saying,  “a  firewall  builds  a  blockade  between  an  internal 
network  that  is  assumed  to  be  secure  and  trusted,  and  another  network,  usually  an  external 
(inter)network,  such  as  the  Internet,  that  is  not  assumed  to  be  secure  and  trusted.”  Many  popular 
examples  of  firewall  software  for  computers  exist  such  as  ZoneAlarm  [14]  and  Comodo  [15] 
for  Windows  systems  and  iptables  [16]  for  Finux  systems.  Firewalls  exist  for  both  personal 
computers  and  for  servers. 

Routers  have  firewall  functionality  included  as  they  are  a  vital  component  of  network  defense. 
Organizations  construct  networks  using  the  notion  of  autonomous  systems  (ASs),  in  which  the 
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organization  monitors  all  of  its  own  resources  [17].  Border  routers ,  those  that  connect  an  AS 
to  the  rest  of  the  Internet,  have  integrated  firewalls  in  order  to  provide  defense  of  the  network 
against  threats  from  the  Internet  at  large. 

Firewalls  are  configured  by  the  user  to  deny  forwarding  of  network  traffic  based  on  hierarchies 
of  rules.  Traffic  types,  such  as  ICMP,  may  be  blocked.  Port  ranges,  such  as  that  of  traceroute 
(33434  to  33534),  may  be  blocked.  Other  criteria  such  as  IP  addresses,  flags  and  options  may 
also  be  used  to  block  traffic. 

2.2.5  Honeypots 

Honeypots  are  machines  that  appear  to  be  vulnerable  computers  but  are  actually  programs  de¬ 
signed  to  lure  attackers.  They  offer  a  form  of  deception  that  tricks  an  attacker  into  believing 
they  have  uncovered  valuable  information,  or  tricks  them  into  exposing  their  attack  methods 
while  attempting  to  compromise  the  honeypot.  Honeyd  [18],  HoneyClient  [19],  The  Honeynet 
Project  [20]  and  Honeymonkey  [21]  are  examples. 

LaBrea  [22]  is  a  form  of  honeypot  that  takes  over  unused  IP  addresses  within  a  network  address 
space  and  attempts  to  answer  all  connection  attempts  from  outside  sources.  This  method  is 
especially  useful  against  automated  attacks  as  it  can  keep  the  attacking  script  busy  for  a  long 
time  by  continually  deceiving  the  script  into  acting  as  if  the  service  for  which  it  is  probing 
is  available.  Furthermore,  this  slows  down  the  attacker’s  probe  rate  by  tricking  the  attacker 
into  a  potentially  long  wait  period.  LaBrea  is  most  directly  related  to  the  research  presented 
here  in  that  it  attempts  to  deceive  an  attacker  of  the  existence  of  devices  at  unused  addresses. 
Furthermore,  it  attempts  to  simulate  the  existence  of  running  services  at  the  deceptive  address. 


2.3  Review  of  Literature 

Today,  there  are  at  least  two  methods  of  employing  deception  in  cyberspace.  The  first  is  through 
obfuscation ,  in  which  defensive  software  tools  mask  identifying  attributes  of  a  host  computer 
to  prevent  “fingerprinting.  [23]”  The  second  method,  the  use  of  honeypots ,  lures  the  adversary 
into  exploiting  seemingly  vulnerable  computers  which  are,  in  reality,  programs  running  on  a 
host  computer  expressly  for  the  purpose  of  deceiving  an  adversary  into  exposing  his  or  her 
tactics  [24].  What  follows  is  a  discussion  of  representative  research  of  MILDEC  in  the  physical 
domain.  We  also  discuss  research  that  illustrates  how  deception  in  the  physical  domain  has  been 
adapted  to  implement  obfuscation  and  honeypots  in  the  cyber  domain. 
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2.3.1  Military  Deception  in  the  Physical  Domain 

JP  3-13.4,  released  by  the  Chairmain,  Joint  Chiefs  of  Staff  (CJCS)  on  13  July  2006,  provides 
the  definition  of  MILDEC  used  by  the  U.S.  armed  forces.  According  to  JP  3-13.4,  MILDEC 
comprises  six  principles: 

1.  focus:  the  deception  must  target  the  adversary  decision  maker  capable  of  taking  the  de¬ 
sired  action(s); 

2.  objective:  the  deception  must  cause  an  adversary  to  take  (or  not  to  take)  specific  actions, 
not  just  to  believe  certain  things; 

3.  centralized  planning  and  control:  MILDEC  operations  should  be  centrally  planned  and 
directed  in  order  to  achieve  unity  of  effort; 

4.  security:  friendly  forces  must  deny  knowledge  of  a  force’s  intent  to  deceive  and  the  exe¬ 
cution  of  that  intent  to  adversaries; 

5.  timeliness:  a  deception  operation  requires  careful  timing;  and 

6.  integration:  fully  integrate  each  military  deception  with  the  operation  that  it  is  supporting. 

JP  3-13.4  also  provides  guidance  on  determining  the  goals  and  objectives  of  deception  opera¬ 
tions  [3]. 

Fowler  and  Nesbit  [25]  provide  several  examples  of  tactical  MILDEC  in  air  and  land  warfare 
and  identify  six  “rules”  a  deception  must  follow  if  it  is  to  be  successful.  First,  “a  deception 
must  be  one  that  causes  the  enemy  to  believe  what  he  expects.”  Second,  timely  feedback  on 
the  enemy’s  reaction  to  a  deception  is  essential.  Third,  the  deception  must  be  integrated  with 
other  operations.  Fourth,  preventing  the  disclosure  of  information  regarding  true  activities  is 
essential.  Fifth,  the  level  of  realism  required  by  the  deception  is  a  function  of  the  adversary’s 
capability  to  analyze  the  situation.  Finally,  “the  most  effective  deception  will  be  imaginative 
and  creative.” 

Whaley  [26]  describes  deception  in  two  categories:  hiding  the  real,  or  dissimulation-,  and  show¬ 
ing  the  false,  or  simulation.  According  to  Whaley,  dissimulation  is  that  part  of  a  deception  that 
is  concealed  from  the  adversary.  Simulation  is  the  overt  part  of  a  deception  presented  to  the 
adversary.  The  research  presented  herein  employs  both  categories. 

2.3.2  Military  Deception  in  the  Cyber  Domain 

From  the  perspective  of  Whaley’s  taxonomy,  we  consider  the  work  done  by  others  in  exploring 
the  denial  of  information.  What  Whaley  calls  dissimulation  is  also  known  as  obfuscation.  For 
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example,  consider  an  implementation  of  TCP/IP  in  which  the  generated  traffic  contains  arti¬ 
facts  that  allow  their  host  OSs  to  be  identified  [27].  Smart  et  al.  [28]  describe  the  design  and 
implementation  of  a  scrubber  that  obfuscates  the  behavior  of  the  TCP/IP  stack  to  prevent  iden¬ 
tification  of  the  host  OS.  This  concealment  of  the  host  identification  is  a  form  of  dissimulation. 

Rowe  and  Rothstein  [29]  consider  Fowler  and  Nesbit’s  rules  and  adapt  them  to  application  in 
cyber  war.  They  also  consider  Dunnigan  and  Nofi’s  proposed  taxonomy  of  deception  [30]  and 
provide  an  assessment  of  how  useful  each  type  of  attack  is  in  information  systems.  Dunnigan 
and  Nofi  identify  nine  types  of  deception.  Applicable  to  our  discussion  is  concealment  (what 
Whaley  calls  dissimulation)  and  lies  (which  may  include  simulation).  In  Rowe’s  assessment, 
“concealment  of  resources”  is  relatively  unimportant  (assessed  2  out  of  10  on  an  internal  scoring 
system).  Using  the  deception  methodology  presented  in  this  research,  concealment  of  resources 
is  quite  valuable,  requiring  at  times,  that  nodes  be  concealed  from  an  adversary’s  view.  Rowe 
and  Rothstein  assess  “lies”  to  be  very  important  (i.e.,  a  score  of  10  out  of  10)  which  is  consistent 
with  our  research.  As  Rowe  and  Rothstein  point  out,  “The  best  things  to  lie  about  could  be  the 
most  basic  things  that  matter  to  an  attacker:  the  existence  of  resources  and  his  or  her  ability 
to  use  them.  [29]”  The  research  presented  herein  will  not  only  conceal  resources  but  lies  to  an 
adversary  about  the  existence  of  a  resource  (network  node)  that  does  not  exist. 

In  an  example  of  dissimulation,  Huber  [31]  evaluates  the  effectiveness  of  an  original  approach  to 
network-based  obfuscation  known  as  Systemic  Network  Obfuscation  System  (SNOS).  SNOS 
is  a  Windows-based  program  that  attempts  to  defeat  host  identification  based  on  its  network 
traffic,  and  it  is  similar  to  the  work  done  by  Smart  et  al.  SNOS  is  capable  of  manipulating 
network  traffic  at  any  layer  of  the  Open  System  Interconnection  (OSI)  model  except  for  the 
physical  layer.  It  manipulates  data  fields  within  passing  network  traffic  to  alter  certain  features 
that  would  reveal  the  host  OS  of  the  sending  device.  Huber  evaluates  the  effectiveness  of  SNOS 
against  an  existing  obfuscation  tool  known  as  OSfuscate  [32].  In  addition  to  its  effectiveness, 
SNOS  is  also  evaluated  for  performance  based  on  its  impact  to  network  latency. 

The  work  presented  by  Smart  et  al.  [28]  and  Huber  [31]  employ  only  the  principal  of  dissimula¬ 
tion  to  obfuscate  network  hosts.  The  research  presented  herein  obfuscates  network  hosts  in  that 
the  deceptive  traffic  to  the  adversary  does  not  reveal  the  host  OSs  of  the  routers  within  the  de¬ 
fended  network.  This  was  not  an  intentional  design  specification  but  rather  a  by-product  of  our 
implementation.  In  addition  to  obfuscating  the  routers  in  a  defended  network,  our  implementa¬ 
tion  also  attempts  to  deceive  an  adversary  as  to  the  existence  of  routers  through  simulation. 
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Beyond  obfuscation  research,  the  work  presented  by  Frederick  [33]  explores  the  state  of  the 
art  in  honeypots  by  testing  the  low-interaction  honeypot  software,  Honeyd  [18],  on  an  Internet¬ 
facing  network  without  the  protection  of  a  firewall.  Honeypots  perform  by  Whaley’s  definition 
of  simulation  by  providing  the  illusion  of  an  existing  network  resource. 

Zhang  et  al.  [34]  describe  the  use  of  honeypots  as  an  active  defense  for  networks,  survey  the 
current  state  of  the  art,  and  classify  the  typical  uses  of  honeypots  in  network  defense. 

2.4  Contributions  in  Context 

In  summary,  this  thesis  makes  the  following  contributions:  (1)  Introduces  a  novel  methodology 
for  topological  deception,  (2)  implements  in  a  Linux  kernel  module  the  described  methodology, 
and  (3)  demonstrates  the  workings  of  such  in  a  synthetic  network. 

An  adversary  using  the  traceroute  program  may  be  deceived  as  to  the  physical  topology  of  a 
computer  network  through  the  careful  manipulation  of  traffic  leaving  the  network  in  response 
to  the  traceroute  probe,  thus  masking  the  importance  of  key  nodes  along  the  actual  route. 

The  implementation  provided  herein  is  demonstrated  to  work  in  a  laboratory  environment  how¬ 
ever  evaluation  of  its  ability  to  deceive  real  adversaries  in  a  production  network  environment  is 
left  to  future  work.  In  §  5.2  we  offer  a  discussion  of  possible  considerations  for  evaluating  the 
usefulness  of  the  deception  implementation. 
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CHAPTER  3: 
METHODOLOGY 


Network  defense  is  an  operational  reality.  A  spectrum  of  options  is  available  to  protect  a  net¬ 
work  from  adversarial  probing  and  scanning.  Table  3.1  presents  three  options  that  we  review 
briefly.  The  options  are  not  an  exhaustive  list  of  the  methods  of  network  defense  available,  but 
rather,  speak  to  defense  in  terms  of  what  kind  of  traffic  to  permit. 

One  option  for  network  defense  is  to  deny  access  to  all  services  within  the  network.  This  is 
a  seemingly  easy  and  straightforward  approach  to  insulate  the  network  from  attack.  Unfortu¬ 
nately,  complete  denial  of  all  traffic  also  impacts  the  network’s  usability  for  legitimate  users 
and  thus  can  defeat  the  purpose  of  the  network  (e.g.,  to  share  resources  or  content).  Services 
provided  by  the  network  should  be  available  to  legitimate  remote  users  even  when  the  network 
is  under  attack. 

Another  option  is  to  deny  certain  services  ( selective  denial )  thereby  allowing  only  legitimate 
traffic  in  as  identified  by  particular  identifying  protocol  fields.  For  example,  ICMP  traffic  may 
be  blocked  at  a  border  router  while  TCP  traffic  is  allowed  in.  Such  an  approach  allows  Internet¬ 
facing  services  such  as  web  servers  to  provide  service,  but  denies  the  defender  from  gaining  any 
intelligence  on  how  the  adversary,  for  example,  uses  ICMP.  Furthermore,  it  denies  the  defender 
the  opportunity  to  place  false  information.  Note  that,  in  general,  selective  denial  is  difficult  to 
do  especially  when  encryption  is  used.  It  is  also  made  difficult  when  several  types  of  traffic  are 
made  to  ride  over  port  80,  the  standard  port  for  Hypertext  Transfer  Protocol  (HTTP).  In  such 
cases,  identifying  traffic  for  selective  denial  is  a  field  of  study  in  its  own  right. 


Technique 

Pros 

Cons 

Complete  Denial 

Insulates  the  protected  net¬ 
work. 

Isolates  the  protected  net¬ 
work. 

Selective  Denial 

Permits  availability  of  select 
services. 

Denies  the  defender  insight 
into  enemy  attack. 

Deception 

Offers  protection  of  network. 
Offers  defender  some  insight 
into  enemy  attack. 

Requires  robust  implementa¬ 
tion. 

Table  3.1:  Options  for  defending  a  network.  Denial  compared  to  deception. 
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A  final  option  is  to  leave  the  network  completely  open  in  the  sense  that  all  services  are  allowed. 
Doing  so  would  permit  forensic  analysis  of  an  adversary’s  attacks,  but  may  unduly  increase  the 
risk  of  harm  to  the  network.  However,  it  is  possible  to  use  deception  on  an  open  network  to  lure 
an  adversary  to  attack  false  targets  or  to  dilute  his  or  her  attack.  Deception  may  offer  the  ability 
to  defend  the  network  in  additional  ways.  Despite  the  advantages  deception  offers  the  defender, 
it  requires  a  robust  implementation  to  account  for  the  many  tools  an  adversary  may  employ  to 
gain  intelligence  against  a  target  network. 

3.1  Design  Overview 

Traceroute  probes  are  active  probes,  most  typically  used  for  diagnostics  and  troubleshooting. 
Probes  are  sent  on  demand  by  a  user  or  an  automated  task,  and  may  be  directed  toward  any 
device  (IP  destination)  within  a  network.  These  active  probes,  by  definition,  involve  injecting 
packets  that  elicit  some  response  from  the  target(s)  in  an  attempt  to  fingerprint,  characterize, 
or  map  the  network.  As  a  result,  the  best  place  to  affect  the  results  of  such  mapping  are  at  the 
ingress  or  egress  points  to  the  network.  An  ingress  point  is  a  border  router  for  an  AS  (introduced 
in  §2.2.4)  that  permits  traffic  into  the  network.  Therefore,  we  consider  a  strategy  whereby 
deceptive  functionality  resides  on  the  border  routers  of  an  AS.  By  deploying  the  deception  at 
a  border  router,  any  designated  device  within  the  AS  or  the  whole  network  is  protected  by  the 
deception. 

In  the  deception  employed  here,  we  focus  specifically  on  deceiving  an  adversary’s  traceroute 
probe  using  an  implementation  deployed  in  a  border  router.  As  discussed  in  §  2.1.4  a  tracer¬ 
oute  probe  elicits  ICMP  Time  Exceeded  messages.  Crucially,  the  path  reported  to  the  prober 
is  a  function  of  the  source  addresses  of  the  ICMP  Time  Exceeded  messages.  These  ICMP 
messages  are  encapsulated  in  an  IP  packet,  the  source  IP  address  of  which  may  be  from  al¬ 
most  any  IP  address.  Through  experimentation  we  found  that  traceroute  does  not  receive  ICMP 
replies  sent  from  Class  D  (multicast  224.0.0.0  to  239.255.255.255)  or  local  host  (127.0.0.0  to 
127.255.255.255)  addresses.  As  a  result  of  this  flexibility,  there  are  many  possible  strategies  to 
implement  deception. 

3.2  Implementation  Requirements 

In  order  for  topological  deception  to  be  successful,  it  must  satisfy  several  criteria.  The  criteria 
is  divided  into  constraints  (the  deception  must  do  something)  and  restraints  (the  deception  must 
not  do  something). 
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Four  operational  constraints  were  imposed.  The  first  constraint  imposed,  following  from  Fowler 
and  Nesbit’s  [25]  first  rule,  is  that  the  deception  must  be  “believable.”  Anyone  probing  the  net¬ 
work  must  see  something  that  appears  to  be  the  actual  network.  The  idea  is  that  the  deception 
should  present  an  external  consistency  in  which  the  deception  does  not  betray  the  truthful  under¬ 
lying  network.  For  example,  if  a  physical  network  provides  a  web  server,  the  deception  should 
not  try  to  convince  the  adversary  that  no  web  server  exists  on  the  network.  Conversely  is  the  idea 
of  internal  consistency,  that  the  deceptive  network  will  look  consistent  from  different  vantage 
points  outside  the  network.  For  example,  for  ASs  that  have  multiple  border  routers,  different 
deception  schemes  should  be  employed  at  each  router  but  each  deception  scheme  should  rein¬ 
force,  not  contradict,  another.  For  the  experiment  presented  herein,  this  constraint  is  satisfied 
by  the  use  of  a  single  border  router. 

Second,  the  deception  must  account  for  two  key  metrics.  The  TTL  of  a  packet  and  the  time  it 
takes  for  a  packet  to  reach  its  destination  are  loosely  correlated.  Due  to  the  loose  correlation  it 
may  be  possible  that  an  inconsistency  could  allow  for  an  adversary  to  ascertain  that  deception  is 
in  use.  However,  ensuring  that  these  metrics  are  consistent  is  vital  in  upholding  the  plausibility 
of  the  deception.  Because  a  single  node  is  deploying  the  deception,  it  must  send  the  packets 
with  TTL  values  and  delay  times  that  enforce  the  illusion  that  packets  are  originating  from 
nodes  that  are  increasingly  more  distant  from  the  adversary  than  the  deceiving  node.  Should  a 
deceptive  packet  be  returned  to  the  adversary  too  fast  or  in  a  time  that  is  equal  to  the  time  taken 
for  every  other  reply  in  the  probe  to  be  sent,  the  deception  is  exposed. 

Third,  the  deception  must  be  easily  deployed  or  withheld.  This  feature  facilitates  making  modi¬ 
fications  to  the  deceptive  topology.  Additionally,  the  deception  might  need  to  be  disabled  during 
periods  of  network  maintenance.  Otherwise,  leaving  the  deception  running  while  the  protected 
devices  are  legitimately  offline  would  expose  the  deception.  The  issue  of  managing  the  de¬ 
ployment  of  the  deception  is  an  important  one  and  may  be  left  for  a  commander  to  decide. 
However,  the  operation  of  the  deception  may  be  left  to  network  managers  who  must  administer 
the  deception.  The  issues  of  such  management  are  left  to  future  work. 

Finally,  the  deceptive  route  must  be  easily  configurable  and  flexible.  Routine  changes  in  the 
physical  topology  or  changes  in  the  deception  method  employed,  will  necessitate  changes  in 
the  deceptive  route.  Furthermore,  because  an  AS  may  have  multiple  border  routers,  the  decep¬ 
tive  route  must  be  tailored  to  be  consistent  from  the  perspective  of  each  border  router.  Such 
flexibility  of  configuration  enables  us  to  meet  the  requirement  of  providing  the  internal  consis- 
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tency  introduced  with  the  first  constraint. 


In  addition  to  the  operational  constraints,  two  restraints  were  imposed.  First,  the  deception  must 
not  interfere  with  other  mission-critical  services  offered  by  the  defended  network.  The  purpose 
of  the  deception  is  to  foil  attempts  to  accurately  determine  network  topology.  The  purpose  is 
not  to  prevent  access  to  legitimate  and  necessary  services  offered  by  the  network.  Services 
such  as  File  Transfer  Protocol  (FTP),  Virtual  Private  Network  (VPN),  Secure  Shell  (SSH),  web 
browsing,  and  others  should  not  be  impeded  by  the  deployment  of  the  deception  unless  such 
services  were  the  specific  targets  of  the  deception.  In  the  general  case,  the  services  provided  by 
the  network,  such  as  those  enumerated  above,  must  be  available  to  legitimate  remote  users. 

The  second  restraint  imposed  is  that  the  deception  must  only  be  employed  on  a  per-destination 
basis,  meaning  that  the  deception  is  deployed  only  for  designated  IP  addresses  or  prefixes.  For 
an  example  of  the  necessity  of  this  restraint,  depending  on  the  real  topology,  the  deception 
would  be  exposed  if  for  any  destination  IP  address  the  same  (deceptive)  route  was  always  re¬ 
turned.  Consider  the  network  topology  shown  in  Figure  3.1.  If  the  same  route  were  to  be  given 
as  a  response  to  traceroute  probes  directed  at  every  node  in  the  network  the  adversary  would 
surely  surmise  that  some  form  of  deception  is  being  employed.  For  the  experiment  performed 
in  this  research,  the  destination  IP  address  was  that  of  a  web  server.  A  more  robust  deception 
would  employ  a  slightly  different  deceptive  route  for  every  node  on  the  network  yet  every  de¬ 
ceptive  route  would  be  consistent  with  all  others.  Such  is  left  to  future  research.  It  should  be 
noted  that  a  limitation  of  our  implementation  is  that  for  a  traceroute  probe  to  any  node  other  than 
the  web  server  the  truthful  route  is  provided  to  the  adversary.  A  more  robust  approach  would 
be  to  employ  variations  on  the  deceptive  route  for  each  node  in  the  network  or  for  designated 
high-value  nodes. 


3.3  Network  Design 

We  conducted  an  experiment  using  a  simple  three-node  network  comprised  of  the  adversary’s 
workstation,  a  target  web  server  and  an  “intelligent”  router  separating  the  two.  The  intelligent 
router  is  the  device  charged  with  identifying  incoming  traceroute  probes  sent  using  UDP  that 
are  destined  for  the  web  server  and,  in  return,  providing  deceptive  responses  to  the  adversary. 

We  also  used  more  complicated  network  topologies  in  our  experiments.  We  used  a  Watts- 
Strogatz  [35]  model  to  generate  a  synthetic  topology  for  experimentation  due  to  its  random 
nature  and  its  tendency  to  cause  high  clustering  of  nodes.  We  realize  that  this  is  not  representa- 
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Figure  3.1:  Experiment  topology  implemented  in  virtualization.  All  IP  addresses  are  on  the 
192.168.000.000  subnet. 

tive  of  any  real  network  but  we  use  it  for  our  experiments  due  to  the  model’s  bias  toward  creating 
graphs  with  high  clustering  and  short  path  lengths  between  pairs  of  nodes.  Our  implementation 
of  topological  deception  is  generalized  to  take  as  input  any  true  network  topology.  Thus,  for  our 
experiments  it  is  acceptable  to  use  the  a  graph  generational  algorithm.  The  generated  graph  met 
two  requirements  for  later  experiments.  The  protected  network  had  to  contain  at  least  four  nodes 
and  one  of  the  nodes  added  to  the  original  three-node  model  had  to  be  included  in  the  deceptive 
route  being  reported  to  the  adversary’s  traceroute  probe.  This  was  necessary  as  adding  only  one 
new  node  to  the  protected  graph  would  add  no  substantial  value  to  the  experiment.  Furthermore, 
at  least  one  of  the  new  nodes  had  to  be  in  the  deceptive  route  to  verify  that  its  representation  in 
the  deceptive  route  would  not  conflict  with  its  existence  in  the  actual  network.  This  supported 
our  restraint  of  not  interfering  with  mission-critical  services.  The  resulting  topology  is  shown 
in  Figure  3.1. 

3.4  Software  Selection 

A  single  workstation  running  Ubuntu  12.04. 1  was  used  for  all  experimentation.  We  used  Graph¬ 
ical  Network  Simulator  (GNS3)  [36]  as  the  operating  environment  for  all  experiments  as  it  al¬ 
lows  virtual  machines,  routers,  and  the  connecting  links  to  be  assembled  and  changed  quickly 
without  the  overhead  of  assembling  and  reconfiguring  candidate  topologies  in  expensive  hard¬ 
ware.  Henceforth  we  assume  that  all  hardware  and  software  are  components  of  the  virtual 
environment  provided  by  GNS3. 

A  virtual  Cisco  3725  router,  typical  of  small  to  medium  sized  offices,  was  used  for  each  of 
the  nodes  described  by  the  generated  Watts-Strogatz  model  except  for  the  intelligent  router  and 
the  web  server.  The  actual  router  used  does  not  impact  the  results  of  our  experiment.  These 
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Figure  3.2:  Example  of  betweenness  centrality.  Node  2  in  (a)  has  the  highest  Cb,  1.  In  (b)  all 
nodes  have  equal  Cb,  0. 

routers  simply  provided  the  node  count  necessary  to  implement  a  viable  deception.  Each  router 
ran  Cisco’s  IOS  version  12.4(15)T14  and  had  Routing  Information  Protocol  (RIP)  enabled.  We 
chose  to  use  RIP  for  expediency  of  configuration,  however  we  could  have  used  static  routing 
instead. 

Both  the  adversary’s  workstation  and  the  web  server  ran  Lubuntu  12.04.1  [37]  with  kernel 
version  3.20.  The  adversary’s  workstation  had  traceroute  installed.  The  web  server  had  Apache 
installed.  With  these  exceptions,  both  machines  had  an  otherwise  default  installation.  All  three 
computers  had  Wireshark  [38]  installed  to  aid  in  debugging  the  software  developed  for  the 
intelligent  router. 

The  intelligent  router  used  a  lightweight  Linux  distribution  known  as  SliTaz  4.0  [39]  using 
kernel  version  2.6.37.  We  selected  this  OS  because  the  simplicity  of  its  design  facilitated  fast 
kernel  compile  times,  kernel  module  development  and  packaging  of  custom  software  as  needed. 
In  addition  to  the  custom  kernel  module  that  provided  the  core  functionality  of  this  research, 
the  intelligent  router  also  ran  Quagga  [40],  a  networking  protocol  suite  that  provides  an  imple¬ 
mentation  of  RIP  for  Linux  systems  thus  allowing  the  intelligent  router  to  communicate  with 
the  Cisco  routers. 

3.5  Vulnerability  Analysis 

An  important  consideration  was  identifying  what  constitutes  a  “high-value”  node.  A  high-value 
node  could  be  a  device  that  is  running  a  particular  service  or  set  of  services,  a  router  with  known 
vulnerabilities  or  a  workstation.  Essentially,  a  high-value  node  is  one  whose  exploitation  would 
cause  the  biggest  impact  to  the  network.  There  are  many  metrics  for  evaluating  the  high-value 
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targets  of  a  network  or  the  network’s  infrastructure.  While  we  do  not  advocate  any  particular 
notion  of  value,  we  use  the  well-established  notion  of  betweenness  centrality  in  determining  a 
node’s  value. 

Betweenness  centrality,  often  abbreviated  Cb,  is  a  measurement  taken  at  either  a  node  or  a  link 
that  provides  representation  of  how  important  the  node  or  link  is  to  the  rest  of  the  network. 
Freeman  [41]  describes  the  notion  of  point  centrality  as  a  structural  property  of  betweenness, 
explaining,  “a  point  in  a  communications  network  is  central  to  the  extent  that  it  falls  on  the 
shortest  path  between  pairs  of  other  points.”  A  node  with  high  Cb  has  greater  ability  to  relay 
or  withhold  communication  between  the  pairs  of  nodes  it  connects  compared  to  other  nodes  on 
the  path  between  the  same  pair.  It  follows  then  that,  should  a  node  with  high  Cb  be  disabled  by 
attack  or  other  action,  its  inability  to  relay  communication  greatly  impacts  the  pairs  of  nodes  it 
connects. 

Given  a  strategy  for  the  deception  type,  and  which  nodes  to  protect,  we  ask  the  question,  how 
can  deception  protect  vulnerable  nodes?  Specifically,  given  the  ability  to  add  a  single  link  (or, 
more  appropriately,  the  illusion  of  such  a  link  using  deceptive  techniques)  to  the  graph  in  order 
to  protect  a  designated  “most  vulnerable  node,”  where  should  that  link  appear?  By  asking  these 
questions  we  expect  to  find  answers  that  allow  us  to  minimize  the  maximum  Cb  in  the  network. 

We  tested  two  approaches  to  this  question.  The  first  approach  was  simple:  find  the  two  nodes  in 
the  network  with  the  lowest  Cb  and  connect  them.  The  second  approach,  against  which  the  first 
was  compared,  was  to  exhaustively  enumerate  each  possible  network,  adding  one  link  between 
every  pair  of  nodes  in  the  network,  and  returning  the  model  of  the  network  with  the  lowest 
overall  Cb-  The  first  approach  produced  results  that  were  equal  to  that  of  the  second  approach 
50%  of  the  time  for  randomly  generated  input  networks.  However,  the  second  approach  proved 
to  generate  graphs  that  frequently  showed  lower  Cb  than  the  first.  The  results  generated  by  the 
selected  approach  formed  the  basis  of  the  deceptive  route  presented  to  an  adversary’s  traceroute 
probe. 

It  is  important  to  note  that  the  second  approach  is  inefficient  in  that  the  input  network  is  scanned 
once  for  each  combination  of  node  pairs  in  the  network.  For  n  nodes,  the  network  is  scanned 
(2)  times.  For  example,  a  network  with  8  nodes  is  scanned  28  times.  Finding  a  more  efficient 
method  is  left  to  future  research. 

To  illustrate  the  point  that  a  vulnerable  node  is  one  that  has  a  high  Cb,  consider  the  three- 
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options  deceptiveroute  hop_addr  =  192. 168.0.2 , 192. 168.4.2  ,192.  168.5.2 

Figure  3.3:  The  kernel  configuration  file  for  the  deception  implementation. 

node  network  shown  in  Figure  3.2.  In  Figure  3.2a  node  2  has  Cb=1-  It  is  a  member  of  the 
shortest  path  between  nodes  1  and  3  and  a  successful  attack  on  it  would  prevent  those  nodes 
from  communicating.  Comparatively,  an  attack  on  nodes  1  or  3  would  not  prohibit  nodes  1  and 
2  or  2  and  3  from  communicating.  Now  consider  Figure  3.2a  in  which  a  deceptive  link  has  been 
added  between  nodes  1  and  3.  Now,  all  nodes  have  a  perceived  Cb=0  and  the  vulnerability  of 
node  2  is  masked.  This  action  does  not  prevent  node  2  from  being  attacked.  Rather,  node  2  is 
less  attractive  as  a  target  from  the  adversary’s  perspective. 

Having  determined  that  a  vulnerable  node  is  one  with  high  Cb,  a  method  was  needed  to  find  that 
node  and  minimize  its  Cb-  For  this  we  turned  to  the  NetworkX  [42]  library  for  the  Python  [43] 
programming  language.  NetworkX  provides  two  features  useful  for  this  experiment.  It  was 
used  to  generate  a  Watts-Strogatz  model  of  the  protected  network  that  had  a  minimum  of  four 
nodes,  yet  were  not  connected  strictly  end-to-end.  In  addition,  it  is  capable  of  reading  input 
files  that  describe  a  graph  and  returning  the  Cb  values  for  each  node  in  the  graph. 

We  developed  a  Python  script  that  takes  an  input  file  describing  a  true  network  topology.  The 
input  file  contains  a  list  of  all  nodes  in  a  network,  each  node’s  IP  address  and  each  of  the  links 
in  the  network.  The  script  then  performs  an  exhaustive  search  of  the  graph,  testing  the  resulting 
overall  Cb  after  adding  a  single  new  link  between  each  pair  of  nodes  in  the  graph.  Figure  3.4 
is  the  algorithm  that  describes  this  process.  The  output  of  the  algorithm  is  what  our  deception 
will  implement  to  minimize  the  maximum  Cb  • 

NetworkX  was  then  used  to  find  the  new  shortest  path  between  the  intelligent  router  and  the 
web  server  in  the  network  with  the  minimized  Cb-  The  output  of  this  script  is  a  description  of 
the  new  shortest  route,  specified  by  IP  address  only,  provided  in  a  configuration  file  to  be  used 
as  input  to  a  kernel  module.  The  resulting  configuration  file,  named  deceptiveroute  .  conf , 
is  shown  in  Figure  3.3  where  deceptiveroute  is  the  name  of  the  module  and  hop_addr  is  the 
name  of  the  variable  to  be  initialized  with  the  following  data  (in  this  case,  IP  addresses). 

The  configuration  file  must  be  placed  in  /etc/modprobe  .d/  and,  once  the  kernel  module  is 
compiled,  loaded  using: 
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Data:  graph  g 

Result:  The  single  new  edge  that  produces  min(CB)  for  graph  g 
min_betweenness  = 
for  each  node  i  in  g  do 
for  each  node  j  in  g  do 
if  i  !=  j  then 

new  edge  e  =  (i,j); 
new  graph  h  =  g.copy(); 
h.add_edge(e); 

max(CB)  =  find_max_CB_in(h); 
if  max(CB)  <  minjbetweenness  then 
minimum  =  max(CB); 
a  =  i; 


b=j; 


end 

end 

end 

return  (a,b) 


end 


Figure  3.4:  This  function  returns  an  edge  whose  inclusion  in  graph  g  produces  the  lowest  Cb- 


#  modprobe  deceptiveroute 


The  following  section  describes  the  implementation  details  of  the  kernel  module. 


3.6  Kernel  Module  Implementation  Details 

We  considered  two  methods  of  deceiving  a  traceroute  probe  of  the  route  to  a  protected  node.  In 
the  physical  domain,  an  EW  suite  has  the  capability  to  either  saturate  the  radio  frequency  (RF) 
spectrum  in  response  to  an  adversary’s  radar  sweep  or  it  may  subtly  alter  the  attributes  of  the 
adversary’s  radar  sweep  response  so  as  to  disguise  the  actual  distance  between  the  adversary 
and  target.  Likewise,  a  response  to  a  traceroute  probe  may  be  “noise”  in  the  form  of  Time 
Exceeded  messages  with  randomly  generated  source  IP  addresses  for  each  reply  packet.  Such 
a  deception  may  prove  valuable  in  frustrating  automated  traceroute  probes  as  with  the  method 
employed  by  LaBrea  [22].  Or,  the  deceptive  response  may  be  a  plausible  and  complete  path  to 
the  target.  Both  methods  were  implemented  during  our  experimentation.  The  implementation  of 
noise  was  the  first  milestone  we  set  to  prove  the  overall  feasibility  of  deceiving  traceroute.  We 
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hop_addr 

Initialized  from  configuration  file. 

arr_argc 

Initialized  to  the  number  of  IP  addresses  in  hop_addr. 

preserve_tfi 

Initialized  to  zero.  Stores  incoming  packet’s  TTF  from  start  of  prerouting 
hook  until  end  of  postrouting  hook. 

DEFAUFT_TTF 

Initialized  to  65  per  RFC  1700  with  1  added  to  account  for 
programming  logic. 

router_ip 

192.168.0.2 

webserver_ip 

192.168.5.2 

Table  3.2:  Variables  initialized  at  kernel  load  time. 


used  a  random  number  generator  to  generate  random  source  IP  addresses,  what  we  considered 
to  be  the  “noise.”  The  remainder  of  our  discussion  focuses  on  providing  a  plausible  path  to  an 
adversary’s  traceroute  probe. 

The  heart  of  the  deception  lies  in  the  implementation  of  a  Linux  kernel  module.  There  is  a  route 
to  the  web  server  in  which  one  of  the  hops  is  a  node  with  the  highest  Cb  value  in  the  network. 
The  configuration  file  used  as  an  input  to  the  kernel  module  describes  a  route  that  bypasses  the 
vulnerable  node,  thus  lowering  its  perceived  Cb  and  making  it  a  less  attractive  target  for  attack. 

Several  variables  are  initialized  when  the  kernel  module  is  loaded.  Table  3.2  details  the  im¬ 
portant  variables.  The  variable  arr_argc  contains  a  count  of  the  number  of  elements  passed  to 
hop_addr  and  represents  the  maximum  number  of  hops  provided  in  the  deceptive  route.  The 
recommended  default  TTL  value  given  by  IANA  [44]  is  64.  However,  many  vendors  choose 
different  values  such  as  32,  128  and  255.  The  Cisco  routers  used  in  our  experiment  have  a 
default  TTL  of  255.  The  DEFAULT_TTL  variable  in  the  reply  message  may  be  set  to  one  of 
these  values  if  there  is  a  desire  to  make  the  deceiving  node  appear  to  be  a  device  from  a  different 
vendor.  There  are  methods  to  determine  a  device  type  based  on  attributes  other  than  its  default 
TTL  but  masking  those  attributes  is  outside  the  scope  of  this  research. 

In  order  to  deceive  a  traceroute  scan  and  report  to  it  the  route  described  in  the  configuration  file, 
the  prerouting  and  postrouting  hooks  from  the  Netfilter  [16]  packet  filtering  suite  were  used. 
The  prerouting  hook  is  available  to  intercept  a  packet  as  soon  as  it  arrives  from  the  network 
interface  card  (NIC)  with  no  processing  by  the  host  computer  having  yet  occurred.  Conversely, 
the  postrouting  hook  is  available  to  intercept  a  packet  just  before  it  leaves  the  host  computer 
with  no  further  processing  to  be  done.  See  Figure  3.7  for  an  illustration  of  Netfilter’s  packet 
hooks.  Figure  3.5  is  a  pseudocode  listing  for  our  preroute  function.  Figure  3.6  is  a  pseudocode 
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Data:  socket_buffer  skb 

Result:  For  input  packet  with  TTL>1,  set  TTL=0 

1  ip_header  =  get_ip_header(skb); 

2  if  ip_header->protocol  ==  UDP  then 

3  udp_header  =  get_udp_header(ip_header); 

4  if  (33434  >=  udp_header->dest _port  <-  33434)  AND  ip_header->dest_address  == 
webserver_ip  then 

5  if  ip_header->ttl  ==  1  then 

6  |  preserve_ttl  =  ip_header->ttl; 

7  else  if  ip_header->ttl  >  1  AND  ip_header->ttl  <  arr_argc  then 

8  preserve_ttl  =  ip_header->ttl; 

9  ip_header->ttl  =  0; 

10  ip_header->checksum  ==  new_ip_checksum(ip_header,  ip_header->length); 

11  else  if  ip_header->ttl  ==  arr_argc  then 

12  preserve_ttl  =  ip_header->ttl; 

13  ip_header->dest_addr  =  router_ip; 

14  ip_header->checksum  ==  new_ip_checksum(ip_header,  ip_header->length); 

is  end 

16  end 

17  end 

is  return  ACCEPT_PACKET; 

Figure  3.5:  This  function  identifies  incoming  traceroute  probes  and  conditionally  modifies  the 
TTL  value. 

listing  for  our  postroute  function. 

In  the  prerouting  hook,  the  packet  is  inspected  to  see  if  it  matches  certain  criteria.  Is  it  a  UDP 
packet?  Is  it  destined  for  a  port  in  the  range  of  33434  to  33534?  Recall  from  §2.1.2  that  the 
33434  to  33534  port  range  is  reserved  by  IANA  for  traceroute.  Is  it  destined  for  the  protected 
web  server?  If  the  answer  to  all  of  these  questions  is  “yes”  then  the  kernel  module  begins 
employing  the  deception. 

The  deceptive  hop  that  the  kernel  module  chooses  to  send  in  response  to  the  adversary’s  tracer¬ 
oute  scan  is  dependent  upon  the  TTL  value  of  the  incoming  packet.  Traceroute  sends  packets 
with  incrementally  increasing  TTLs  to  identify  every  node  in  the  path  to  a  destination  thus  the 
first  packet  to  arrive  at  a  border  router  for  an  AS  will  always  have  TTL=1.  Since  all  traceroute 
probes  arrive  at  the  intelligent  router  with  TTL=1,  the  kernel  module  assumes  the  packet  is  the 
first  in  a  set  of  traceroute  packets.  For  the  first  packet,  no  deception  is  returned  to  the  adver- 
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Data:  socket_buffer  skb 

Result:  Transmits  a  deceptive  packet  of  type  Time  Exceeded  or  Port  Unreachable 
ipjieader  =  getjpjieader(skb); 

if  ip_header->protocol  ==  ICMP  AND  ip_header->src_addr  ==  router _ip  AND 
preser\’e_ttl  >  0  then 

icmpjieader  =  getjcmpjieader(ipjieader); 
if  icmp_header->type  ==  ICMP_TIME_EXCEEDED  then 
j  ip  Jieader->src_addr  =  hop_addr[preserve_td- 1  ] ; 
else  if  icmp_header->type  ==  ICMP _P  ORT JJNREACH ABLE  then 
quoted  JpJieader  =  get_quoted_ip_header(ip_header); 
quoted_ip_header->dest_addr  =  webserver_ip; 

quoted  JpJieader- >checksum  =  new  Jpj:hecksum(quoted  JpJieader, 
quoted  JpJieader- >length) ; 

end 

ipjieader->ttl  =  DEFAULT_TTL  -  preservejtl; 

ipjieader->checksum  ==  new_ip_checksum(ip_header,  ipjieader->length); 
delay _sending_packet(DELAY  *  preservejtl); 

end 

preservejtl  =  0; 
return  ACCEPT  JACKET; 


Figure  3.6:  This  function  provides  a  deceptive  Time  Exceeded  or  Port  Unreachable  message  to 
the  adversary. 


sary.  The  intelligent  router  truthfully  replies  to  the  adversary  with  an  ICMP  Time  Exceeded 
message  [5].  The  kernel  module  has  entered  into  its  deception  logic  but  because  the  first  IP 
address  assigned  to  hop_addr  is  that  of  the  router,  no  deception  is  actually  made.  This  design 
decision  was  made  based  on  the  fact  that  the  deception  is  deployed  at  the  border  router  of  an 
AS.  Deceiving  anyone  of  its  presence  on  the  Internet  would  have  potentially  negative  effects  on 
the  AS  and  expose  the  deception. 

When  the  second  traceroute  packet  arrives  (using  UDP  and  a  destination  port  range  of  33434 
to  33534)  it  has  a  TTL  of  two.  The  reply  to  this  packet  is  the  first  to  be  deceptively  returned  to 
the  adversary.  From  the  prerouting  hook,  the  packet’s  TTL  is  saved  in  the  temporary  variable, 
preservejtl,  to  be  accessed  later  in  the  postrouting  hook.  The  packet’s  TTL  is  then  set  to  zero. 
Doing  so  causes  the  packet  to  be  processed  by  the  host  computer  in  the  “local  processes”  bubble 
shown  in  Figure  3.7.  In  effect,  the  intelligent  router  is  tricked  into  processing  the  packet  as  if  it 
expired  while  on  its  way  to  the  destination.  The  host  generates  another  ICMP  Time  Exceeded 
message  and  prepares  the  reply  to  be  sent  to  the  adversary. 
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Figure  3.7:  Linux  packet  routing  scheme.  The  circles  provide  representation  of  the  available 
Netfilter  hooks.  After  [16]. 


When  the  Time  Exceeded  message  arrives  at  the  postrouting  hook  it  has  been  prepared  for 
delivery  to  the  adversary  but  a  few  more  finishing  touches  are  applied  to  it  to  complete  the 
deception.  At  this  point  the  source  IP  address  of  the  Time  Exceeded  message  is  that  of  the 
intelligent  router  (192.168.0.2).  The  source  address  is  thus  replaced  with  the  source  address  of 
the  first  deceptive  hop  as  described  in  the  configuration  file.  In  our  experiment  that  IP  address 
is  192.168.4.2. 

Next,  the  TTL  value  of  the  new  packet  is  decreased  to  reflect  the  metric  the  adversary  expects 
for  a  hop  that  is  more  distant  than  the  intelligent  router.  This  is  where  the  temporary  variable, 
preserve_ttl,  and  the  DEFAULT_TTL  value  is  used.  Recall  that  the  first  packet  sent  in  response 
to  the  traceroute  scan  was  authentic  -  no  deception  was  employed.  Thus  it  left  the  intelligent 
router  with  a  default  TTL  of  64.  With  this  second  packet,  the  adversary  expects  to  reach  a  ma¬ 
chine  that  is  exactly  one  node  more  distant  than  the  intelligent  router.  Thus  the  TTL  of  the  reply 
packet  should  be  one  number  less  than  the  previous  packet.  We  can  accomplish  this  by  using 
the  inbound  packet’s  TTL  that  was  preserved  in  the  prerouting  hook.  The  TTL  of  the  second 
outbound  packet  is  set  to  DEFAULT_TTL  -  preserve_ttl.  Following  this  step,  preserve_ttl  is  set 
to  zero  to  prepare  it  for  the  next  packet. 

Finally,  the  packet  is  delayed  by  a  multiple  of  the  original  packet’s  TTL  value  to  account  for 
the  additional  time  it  should  take  for  the  packet  to  reach  a  hop  that,  again,  is  further  away 
from  the  adversary  than  the  intelligent  router.  The  total  delay  imposed  on  each  packet  was  2 
milliseconds  (ms)  multiplied  by  the  inbound  packet’s  TTL.  A  delay  of  2  ms  was  selected  based 
on  observations  of  the  average  delay  observed  between  hops  while  withholding  the  deception. 
A  better  approach  than  applying  a  multiple  of  a  specific  value  may  be  to  impose  a  delay  based 
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traceroute  to  192.168.5.2  (192.168.5.2) ,  30  hops  max,  60  byte  packets 
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Figure  3.8:  Traceroute  results  with  a  “noisy”  deception  deployed. 


on  a  probability  distribution.  Experiments  in  this  area  are  left  to  future  research.  The  process 
described  repeats  for  each  subsequent  packet  for  which  the  deception  requires  a  Time  Exceeded 
message  in  reply. 

In  a  typical  traceroute  probe,  when  a  traceroute  packet  reaches  its  destination,  the  destination 
computer  replies  with  an  ICMP  Port  Unreachable  message.  A  slightly  different  approach,  as 
that  described  for  a  Time  Exceeded  message,  is  needed  when  sending  the  deceptive  ICMP 
Port  Unreachable  message.  In  the  prerouting  hook,  when  the  incoming  TTL  value  matches 
the  maximum  number  of  hops  (the  value  stored  in  arr_argc)  required  by  the  deception,  the 
destination  address  of  the  packet  is  replaced  by  that  of  the  host  machine.  In  “local  processes” 
the  intelligent  router  creates  the  Port  Unreachable  message  it  would  create  had  the  incoming 


28 


traceroute  packet  been  destined  for  it.  It  then  sends  the  reply  packet  to  the  postrouting  hook.  In 
the  postrouting  hook,  the  same  TTL  manipulation  is  imposed  but  there  is  one  more  thing  that 
must  be  manipulated.  An  ICMP  Port  Unreachable  message  contains  as  its  data  the  message  that 
prompted  the  Port  Unreachable  message  to  be  sent  [45].  In  this  case,  that  seemingly  original 
message  contains  the  intelligent  router’s  IP  address  in  the  destination  field.  If  the  web  server’s  IP 
address  is  not  replaced  in  this  field  the  deception  is  exposed.  Thus,  the  destination  IP  address  is 
replaced  by  the  web  server’s  IP  address  and  the  reply  is  ready  to  be  sent  following  the  necessary 
delay. 

3.7  Noise 

An  early  milestone  in  the  development  of  our  technique  is  the  demonstration  of  the  ability  to 
generate  random  hop  information  in  response  to  a  traceroute  probe.  Reaching  this  milestone 
demonstrates  the  overall  feasibility  of  the  research.  It  also  illustrates  similarities  between  the 
research  herein  and  the  radar  jamming  capability  of  an  EW  suite  or  the  entrapment  capability 
of  LaBrea. 

We  tested  our  ability  to  generate  noise  in  which  we  return  random  IP  addresses  to  an  adversary’s 
traceroute  probe.  The  results  of  such  a  deception  are  provided  in  Figure  3.8.  The  deception 
returns  Time  Exceeded  messages  containing  randomly  generated  source  IP  addresses  thus  the 
adversary  never  receives  the  Port  Unreachable  message  it  expects  and  continues  to  probe  until  it 
reaches  traceroute’s  default  probe  limit  of  30  hops  before  quitting.  Through  experimentation  we 
observed  that  our  implementation  periodically  fails  to  respond  to  incoming  traceroute  packets 
resulting  in  missed  hops  being  reported  by  traceroute.  The  missed  hops  are  denoted  by  the 
asterisks  shown  in  the  output  listing  in  Figure  3.8.  We  leave  resolution  of  the  bug  to  future 
work. 
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CHAPTER  4: 
FINDINGS 


This  chapter  discusses  experimental  results  based  on  our  candidate  network  topology  and  the 
kernel  module  that  implements  the  deception. 

4.1  Experiment  Overview 

Once  a  suitable  deceptive  network  topology  was  selected  it  was  fed  as  input  to  our  Python  script 
that  found  the  node  with  the  highest  Cb  and  suggested  the  addition  of  a  single  new  link  to  lower 
the  Cb-  The  output  of  this  analysis  is  in  the  form  of  a  kernel  module  configuration  file  and 
describes  the  hops  necessary,  including  the  new  link,  to  reach  the  target  web  server.  The  new 
route  described  is  one  that  routes  traffic  around  the  node  with  the  highest  Cb- 

With  the  kernel  module  running,  the  adversary  commences  a  traceroute  scan  against  the  IP 
address  of  the  web  server.  The  intelligent  router,  detecting  the  incoming  scan,  returns  the  pre¬ 
scribed  deceptive  route  to  the  adversary. 

In  order  to  assure  that  the  deception  is  not  impeding  any  form  of  traffic,  the  browser  on  the  ad¬ 
versary’s  machine  is  used  to  view  the  web  pages  provided  by  the  web  server.  Correct  operation 
of  the  deception  was  further  determined  by  attempting  to  traceroute  to  devices  other  than  the 
web  server.  In  such  cases,  the  deceptive  route  was  not  returned  to  the  adversary. 

4.2  Most  Vulnerable  Node 

Figure  4.1  repeats  our  selected  network  topology,  now  with  labels  on  the  routers  for  quick  ref¬ 
erence.  In  terms  of  betweenness  centrality,  the  most  vulnerable  node  is  R3  with  Cb=0.714.  By 
running  our  algorithm  to  minimize  the  maximum  centrality  (in  Figure  3.4),  we  find  that  adding  a 
link  between  the  intelligent  router  and  R5  yields  a  new  betweenness  value  for  R3  of  Cb=0.381. 
Implementing  this  deception  used  the  kernel  configuration  shown  in  Figure  3.3  and  repeated 
here: 


options  deceptiveroute  hop_addr=192. 168.0.2 , 192. 168.4.2 ,192. 168.5.2 


Comparing  the  configuration  file  to  Figure  4.1,  we  note  that  192.168.0.2  corresponds  to  the 
intelligent  router,  192.168.4.2  to  R5,  and  192.168.5.2  to  the  web  server.  Figure  4.1  illustrates 
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Adversary 

.9.100 


Intelligent  Router  -2-2  Web  Server 


R6 


Figure  4.1:  The  deceptive  route  implemented.  The  solid  arcs  represent  the  truthful  route  pro¬ 
vided  to  the  adversary  in  response  to  a  traceroute  probe.  The  dashed  arcs  represent  the  deceptive 
route  supplied  by  the  intelligent  router. 

the  deceptive  route  described  by  the  configuration  file.  The  solid  arcs  represent  the  truthful 
route  provided  to  the  adversary  in  response  to  a  traceroute  probe.  Once  the  probe  reaches  the 
intelligent  router  the  adversary  is  then  deceived  of  the  route  by  the  deception  implementation 
running  on  the  intelligent  router.  The  dashed  arcs  represent  the  deceptive  route  supplied  to  the 
adversary  by  the  intelligent  router. 


4.3  Physical  Route 


We  assessed  the  quality  of  our  deception  using  the  standard  Linux  UDP-based  traceroute: 


#  traceroute  -ql  -n  -N1  192.168.5.2 


As  discussed  in  §2.1.4,  traceroute  by  default  sends  three  probe  packets  per  hop.  The  parameter 
“-ql”  sets  the  number  of  probe  packets  per  hop  to  one.  We  used  this  parameter  only  as  a 


convenience  during  debugging;  it  is  not  fundamental  to  deceiving  the  adversary.  We  also  tried 
values  of  1,  2  and  3  during  testing  of  the  implementation  with  no  obvious  bugs  found.  The 
parameter  “-n”  prevents  traceroute  from  using  the  DNS  to  attempt  to  map  IP  addresses  to  host 
names.  As  with  the  “-ql”  parameter,  the  “-n”  parameter  was  used  as  a  convenience  and  is  not 
fundamental  to  deceiving  the  adversary.  The  parameter  “-N1”  instructs  traceroute  to  have  only 
one  group  of  packets  with  the  same  TTL  in  flight  at  any  time.  The  parameter  “-N”  should  not  be 
confused  with  “-q”.  Where  “-q”  sends  x  number  of  packets  with  the  same  TTL,  “-N”  controls 
how  many  groups  of  packets  with  varying  TTL  traceroute  may  have  in  flight  at  any  time.  The 
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default  operation  for  traceroute  is  to  simultaneously  send  multiple  packets  with  increasing  TTL. 
Doing  so  reduces  the  time  taken  to  complete  the  probe  by  allowing  traceroute  to  identify  several 
nodes  at  once.  In  testing  we  found  our  implementation  to  work  without  the  “-Nx”  parameter, 
and  we  successfully  tested  for  values  of  x  <=  5. 

Figure  4.2  shows  the  output  of  the  traceroute  command  when  the  deception  implementation  is 
withheld.  For  each  hop,  the  IP  address  of  the  forward-facing  interface  of  each  node  is  shown  in 
the  traceroute  output. 

4.4  Deceptive  Route 

Figure  4.3  shows  the  output  of  the  traceroute  command  when  the  deception  implementation 
is  deployed.  From  Figure  4.3  we  can  see  that  the  deception  implementation  reported  to  the 
traceroute  command  the  results  we  expected  given  the  configuration  file  in  Figure  3.3.  Because 
R1  is  in  front  of  the  intelligent  router,  it  truthfully  reports  its  presence  to  the  traceroute  command 
executed  by  the  adversary.  The  intelligent  router  also  truthfully  reports  its  presence  to  the 
adversary  but  all  subsequent  packets  sent  elicit  deceptive  replies  generated  by  the  intelligent 
router  in  response.  In  particular,  the  adversary’s  traceroute  probe  receives  the  Port  Unreachable 
message  it  expects  for  192.168.5.2  thus  the  deception  is  believable. 

4.5  Network  Performance  Impact 

We  performed  a  basic  evaluation  of  the  impact  on  network  performance  the  deception  imposed. 
To  perform  the  evaluation  we  used  Iperf  [46],  a  tool  for  measuring  maximum  UDP  and  TCP 
bandwidth  between  two  points,  a  client  and  a  server.  In  our  evaluation,  the  adversary’s  computer 
served  as  the  Iperf  client  and  the  web  server  acted  as  the  Iperf  server.  We  ran  20  test  iterations. 
For  each  protocol  (UDP  and  TCP)  we  conducted  five  tests  with  the  deception  withheld  and  five 
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Figure  4.3:  Traceroute  results  (after  deception).  Device  labels  from  Figure  4.1  are  added  for 
ease  of  reference. 


more  tests  with  the  deception  deployed. 

The  UDP  tests  were  configured  to  run  on  port  33434  (the  first  port  of  the  standard  traceroute 
range).  Each  test  consisted  of  sending  datagrams  of  1470  bytes  in  size  (the  Iperf  default)  in 
10  seconds.  Bandwidth  was  unaffected  by  the  deployment  of  the  deception,  showing  a  trans¬ 
fer  of  1.25  Megabytes  (MB)  and  893  datagrams  in  each  10-second  test,  for  a  transfer  rate  of 
1.05  Megabits  per  second  (Mbps)  regardless  of  whether  the  deception  was  deployed.  Of  note, 
for  all  10  tests  the  results  were  identical.  The  performance  measured  is  significantly  lower  than 
expected  (100  Mbps)  and  may  be  due  to  the  overhead  imposed  by  executing  the  experiment  in 
a  virtual  machine  (VM),  however  more  testing  in  this  area  is  left  to  future  work. 

For  the  TCP  test  we  again  used  port  33434.  The  Iperf  default  window  size  for  TCP  is  21 
Kilobytes  (KB).  Unlike  the  UDP  results,  the  TCP  results  were  not  identical.  A  minor  variance 
existed  even  amongst  the  results  while  withholding  the  deception.  While  withholding  the  de¬ 
ception  we  observed  the  average  bandwidth  to  be  5.64  Mbps.  With  the  deception  deployed  we 
observed  the  bandwidth  to  be  5.65  Mbps.  We  don’t  consider  the  marginal  improvement  in  per¬ 
formance  with  the  deception  deployed  to  be  attributable  to  the  deception  but  rather  a  symptom 
of  the  variance  in  results  while  testing  using  TCP.  It  is  our  assessment  that  our  implementation 
does  not  negatively  impact  bandwidth  on  the  defended  network.  As  with  the  UDP  tests,  future 
tests  in  the  area  of  TCP  performance  are  left  to  future  work. 
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CHAPTER  5: 

CONCLUSION  AND  FUTURE  WORK 


This  thesis  demonstrates  that  a  UDP-based  traceroute  probe  may  be  deceived  as  to  the  actual 
route  to  a  designated  protected  device.  We  implemented  a  kernel  module  for  a  router  running 
the  Linux  OS.  The  kernel  module  inspects  traffic  at  an  ingress  point  of  an  AS  and  is  able 
to  identify  an  inbound  traceroute  probe  and  reply  to  the  prober  with  a  route  of  the  deceiver’s 
choosing.  The  deceptive  route  is  specified  by  use  of  a  kernel  configuration  file  that  is  read  by 
the  kernel  module  at  run-time.  Having  tested  our  implementation,  we  now  discuss  alternative 
approaches  as  well  as  aspects  of  this  research  which  are  left  to  future  work. 

5.1  Alternative  Approaches 

Before  we  began  our  experiments  we  considered  how  best  to  implement  the  planned  deception. 
The  following  is  a  discussion  of  some  of  the  alternative  implementations  considered.  Each 
approach  has  its  own  advantages  and  disadvantages.  The  practicality  of  implementing  each 
approach  is  left  to  future  work. 

5.1.1  An  Overlay  of  Virtual  Machines 

Early  in  this  research  we  considered  employing  deception  using  a  physical  network  overlaid 
with  VMs.  The  VMs  then  act  as  the  deceptive  nodes  in  a  route.  The  routing  in  such  an  im¬ 
plementation  would  require  the  support  of  a  VM  hypervisor.  Virtualization  software  such  as 
Oracle’s  VirtualBox  [47]  allows  VMs  to  seamlessly  integrate  with  host  networks.  It  would  not 
be  necessary  to  present  a  deceptive  route  to  an  adversary  as  one  would  find  the  VMs  through 
typical  network  surveillance.  Furthermore,  no  intentional  influence  of  router  tables  or  the  per¬ 
formance  of  any  other  manipulation  on  individual  devices  is  fundamental  to  the  implementation 
of  the  deception.  The  mere  existence  and  ordinary  behavior  of  the  VMs  is  sufficient  to  imple¬ 
ment  the  deception.  Instead,  the  challenge  in  this  approach  would  be  to  prevent  the  adversary 
from  discovering  that  the  VMs  are,  in  fact,  virtual.  Refer  to  Figure  5.1a  for  an  illustration  of  an 
overlay  of  VMs. 

We  did  not  pursue  the  VM  implementation  because  we  deemed  it  to  be  too  resource-intensive. 
A  network  of  VMs  overlaying  a  physical  network  would  necessitate  a  greater  investment  in 
hardware.  Not  only  would  hardware  be  required  for  each  physical  node  in  the  network  but  an 
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additional  and  substantial  investment  in  hardware  would  be  needed  to  host  the  required  VMs. 
A  VM  would  be  required  for  every  node  in  the  deception  scheme.  Adding  to  the  challenge 
are  the  issues  of  fault  tolerance  and  management  complexity.  Not  only  would  the  VMs  require 
maintenance  but  so  too  would  the  hardware  that  serves  the  VMs.  There  may  also  be  a  net¬ 
work  performance  penalty  by  integrating  VMs  into  a  real  network.  Recall  the  relatively  low 
performance  we  reported  in  §4.5.  Comparatively,  the  approach  used  herein  requires  minimal 
additional  hardware  investment  or  maintenance  of  VMs  and  does  not  impact  network  perfor¬ 
mance.  Whereas  an  implementation  using  VMs  requires  a  VM  for  every  deceptive  node,  our 
implementation  does  not  require  such  a  one-to-one  mapping.  To  meet  the  minimal  additional 
hardware  requirement  of  our  implementation,  existing  border  routers  may  need  to  be  replaced 
by  other  devices,  such  as  servers,  that  may  act  in  place  of  dedicated  routers  while  running  the 
software  that  implements  the  deception. 

The  use  of  VMs  has  its  merits.  The  advantage  to  using  VMs  is  that  for  every  deceptive  node, 
one  has  at  their  disposal  all  tools  necessary  to  mount  a  plausible  deception.  For  example,  if 
a  deception  required  convincing  an  adversary  of  the  existence  of  a  web  server  at  a  deceptive 
node,  our  implementation  would  require  writing  code  to  accurately  implement  the  facade  of  a 
web  server  whereas  on  a  VM  one  could  simply  install  web  server  software.  Another  benefit 
of  employing  virtual  machines  is  that  it  would  negate  the  necessity  of  having  specially  coded 
software  running  on  an  intelligent  router.  In  our  implementation,  the  specially  coded  software 
is  the  kernel  module  developed  specifically  for  the  purpose  of  deceiving  an  adversary.  Along 
with  the  implementation  come  all  the  software  life-cycle  issues  such  as  maintenance,  evolu¬ 
tionary  updates,  bug  fixes  and  configuration  changes.  In  our  case,  the  responsibility  for  such 
maintenance  falls  on  the  organization  employing  the  deception. 

5.1.2  Shunting 

Another  approach  we  considered  was  to  develop  an  intelligent  router  capable  of  identifying 
attempts  to  probe  the  network  topology,  but  rather  than  have  the  intelligent  router  reply  with 
a  deceptive  route,  it  instead  shunts  the  incoming  network  traffic  into  an  enclave  of  VMs.  See 
Figure  5.1b  for  an  illustration  of  shunting.  The  difference  in  the  shunting  approach  and  the 
approach  described  in  §5.1.1  is  that  the  enclave  of  VMs  is  entirely  self  contained  and  indepen¬ 
dent  of  the  defended  network  rather  than  being  dispersed  over  and  integrated  with  the  defended 
network.  By  shunting  probing  traffic  into  the  enclave,  we  prevent  it  from  causing  congestion  on 
the  defended  network  (as  is  the  case  with  the  implementation  presented  herein)  at  the  expense 
of  having  to  create  a  duplicate  of  the  defended  network,  plus  the  desired  deception  scheme,  in 
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(b)  An  implementation  using  shunting. 


Figure  5.1:  Alternative  implementations  of  deception. 


the  enclave. 

5.1.3  Implementation  in  User  Space 

We  chose  to  implement  the  deception  using  a  kernel  module  instead  of  an  application  in  user 
space.  The  reason  for  this  decision  was  the  assumed  performance  improvement  gained  by 
running  in  kernel  space  rather  than  user  space.  By  implementing  the  deception  in  kernel  space 
we  avoided  having  to  pass  packets  to  user  space,  performing  the  packet  manipulation,  then 
passing  the  packets  back  into  kernel  space  before  transmitting  the  results.  The  trade-off  in  this 
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decision  is  that  the  standard  C  library  is  not  available  in  kernel  space.  Thus,  unusual  solutions 
needed  to  be  coded  for  otherwise  familiar  problems  that  are  more  easily  solved  in  user  space 
(such  as  string  concatenation  and  random  number  generation  for  IP  addresses).  It  may  be  likely 
that  any  performance  gained  by  coding  in  kernel  space  is  likely  negated  by  the  induced  packet 
delay  necessary  to  present  a  plausible  deception. 

5.2  Future  Work 

The  technique  and  implementation  presented  in  this  research  provides  a  potentially  important 
first  step  in  the  use  of  topological  deception,  but  there  is  much  room  for  additional  development. 

5.2.1  Internet  Protocol  version  6 

The  research  presented  herein  involved  the  use  of  Internet  Protocol  version  4  (IPv4)  addresses 
exclusively.  As  the  IPv4  address  space  reaches  exhaustion,  more  organizations  will  begin  using 
Internet  Protocol  version  6  (IPv6)  [48].  Thus,  for  the  deception  implementation  presented  here 
to  remain  relevant,  it  should  be  modified  to  enable  support  for  IPv6  addresses. 

5.2.2  Kernel  Module  vs.  Virtual  Machines 

As  discussed  in  §5.1.1  and  §5.1.2,  different  approaches  would  employ  the  use  of  VMs.  It  is 
left  to  future  work  to  perform  experiments  to  determine  the  benefits  of  each  approach  and  to 
determine  in  which  cases  one  is  more  desirable  than  the  others.  The  following  is  an  example 
of  relevant  research  questions.  Can  VMs  be  configured  to  hide  the  attributes  that  reveal  that  the 
machines  are  virtual?  In  other  words,  can  a  VM  be  configured  to  appear  as  a  real  machine  so  as 
to  thwart  fingerprinting  attempts?  Does  the  integration  of  VMs  with  a  host  network  adversely 
affect  network  performance  compared  to  shunting?  Can  a  network  be  accurately  simulated  us¬ 
ing  virtualization?  Can  the  deception  be  implemented  on  a  production  network  to  assess  which 
parts  of  the  network  are  attacked?  These  research  questions  may  be  tested  using  Iperf  [46], 
nmap  [11]  and  other  performance  measuring  tools.  Future  researchers  may  also  consider  enlist¬ 
ing  the  help  of  human  participants  in  surveys  to  identify  whether  a  remote  machine  is  real  or 
virtual. 

5.2.3  Kernel  Module  vs.  User  Space 

As  discussed  in  §5.1.3  a  different  approach  would  involve  coding  the  implementation  in  user 
space  rather  than  in  kernel  space.  It  is  likely  that  a  more  complete  implementation  of  the  decep¬ 
tion  may  be  achieved  by  coding  in  user  space.  The  kernel  module  employed  herein  is  suitable 
for  the  simple  deception  implemented,  however,  as  more  features  are  added  and  the  potential 
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for  introduction  of  bugs  increases,  the  greater  the  risk  of  causing  the  intelligent  router  to  crash. 
Should  an  implementation  in  user  space  crash,  it  would  not  cause  the  router  to  go  offline.  Fur¬ 
thermore,  a  programmer,  using  the  familiar  C  library,  may  be  able  to  write  an  implementation 
that  more  generally  identifies  a  traceroute  probe  that  is  aimed  at  any  device  in  the  defended 
network  and  is  using  ICMP  or  TCP  rather  than  UDP.  Such  a  general  and  more  flexible  imple¬ 
mentation  is  harder  to  achieve  in  kernel  space  given  the  limited  library  of  C  functions  available 
compared  to  user  space. 

5.2.4  Creating  Robust  Deceptive  Nodes 

Rather  than  employing  VMs  to  gain  a  robust  tool  set,  our  implementation  may  be  further  devel¬ 
oped  to  emulate  certain  services  (such  as  FTP,  SSH,  etc.)  that  may  exist  at  end-point  devices 
such  as  servers.  While  there  are  normally  no  user  accessible  services  on  routers  other  than  those 
afforded  by  ICMP,  the  provision  of  a  deception  that  employs  deceptive  services  is  applicable 
mainly  to  end-points.  Again,  the  example  of  a  web  server  is  appropriate.  If  we  wish  to  con¬ 
vince  an  adversary  that  a  web  server  exists  at  a  deceptive  node,  a  facade  of  a  web  server  must 
be  implemented.  If  an  adversary  is  presented  with  a  suspect  node,  he  may  attempt  to  access 
the  deceptive  web  server  or  other  services  on  that  node  to  determine  its  authenticity.  Using  our 
approach,  the  deception  is  exposed  if  an  adversary  attempts  to  access  any  service  on  a  deceptive 
node.  A  more  robust  approach  would  be  to  have  the  deception  emulate  certain  services  on  a 
given  deceptive  node.  By  doing  so,  the  adversary  is  stalled  by  a  deception  methodology  similar 
to  the  one  implemented  by  LaBrea  [22]  as  discussed  in  §2.2.5. 

5.2.5  Packet  Delay 

Our  implementation  uses  a  deterministic  value  to  cause  delay  between  replies  to  a  traceroute 
probe.  This  is  not  an  ideal  approach  for  two  reasons.  First,  end-to-end  delays  in  a  network 
are  not  always  consistent  due  to  the  variable  effects  of  queuing  and  processing  along  a  path. 
Second,  links  further  away  from  a  prober  are  not  always  slower  to  respond  than  a  closer  link.  A 
more  suitable  approach  to  imposing  accurate  delay  may  be  to  base  the  delay  on  measurements 
taken  from  models  of  the  deceptive  network  the  intelligent  router  is  presenting  to  the  adversary. 

King  [49]  is  a  tool  that  uses  Domain  Name  System  (DNS)  name  servers  to  estimate  host-to-host 
latency.  Gummadi  etal.  [50]  describe  the  technique  used  by  King  as  follows,  “First,  given  a  pair 
of  end  hosts  to  be  measured,  in  most  cases  it  is  possible  for  King  to  find  DNS  name  servers  that 
are  topologically  close  to  the  end  hosts.  Second,  given  a  pair  of  DNS  name  servers,  King  can 
accurately  estimate  the  latency  between  them  using  recursive  DNS  queries.”  With  an  accurate 
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delay  model  obtained  from  King,  one  could  then  estimate  the  appropriate  delays  necessary  for 
the  deceptive  links  used  in  the  deception  scheme.  The  approach  employed  by  King  may  be  used 
in  an  organization  sufficiently  large  enough  to  need  multiple  and  topologically  distributed  DNS 
name  servers.  However,  in  our  experiments,  the  network  was  kept  small  enough  to  demonstrate 
the  proof-of-concept  of  topological  deception  thus  DNS  name  servers  were  unnecessary. 

Zhang  et  al.  [51]  show  that  delay  can  be  estimated  by  placing  a  model  of  the  network  in  a 
plane.  The  Euclidean  distance  between  each  pair  of  connected  nodes  is  then  used  as  the  delay. 
While  this  simple  approach  is  viable,  it  precludes  the  use  of  any  kind  of  scheme  for  introducing 
variance  into  the  delays  between  nodes. 

Lastly,  the  delays  imposed  in  the  deception  may  be  taken  from  direct  measurement  of  the  delays 
that  exist  between  each  node  of  the  defended  network.  For  example,  in  the  topology  shown  in 
Figure  4.1,  the  deceptive  route  resembles  the  actual  route  in  that  the  last  hop  before  reaching  the 
web  server  is  R5.  With  the  deception  withheld,  we  could  run  traceroute  many  times,  perhaps 
100  or  1,000  times,  and  record  the  observed  minimum  and  maximum  packet  delay  between  R5 
and  the  web  server.  We  could  then  use  those  values  as  the  upper  and  lower  bounds  on  the  range 
of  numbers  from  which  to  randomly  select  a  deceptive  delay.  Using  this  method  would  require 
changes  in  the  kernel  configuration  file  to  support  defining  upper  and  lower  bounds  for  packet 
delays  on  a  per-hop  basis.  Unfortunately,  direct  observation  of  packet  delays  is  not  possible  for 
deception  schemes  that  omit  real  nodes  or  introduce  new  deceptive  nodes.  In  such  cases,  one  of 
the  methods  described  above  may  be  used. 

5.2.6  ICMP  and  TCP  Probes 

The  implementation  presented  herein  deceives  traceroute  probes  sent  using  UDP,  the  default 
method  on  Linux  systems.  But  traceroute  is  capable  of  using  ICMP  and  TCP  packets,  circum- 
centing  firewall  schemes  that  block  certain  ports  (such  as  33434  to  33534)  or  protocols  (such  as 
UDP),  to  determine  the  path  to  a  destination.  The  deception  implementation  presented  herein 
does  not  work  for  ICMP  and  TCP  unless  the  source  code  for  our  implementation  is  modified. 
Our  implementation  uses  “if”  statements  to  identify  incoming  packets  as  UDP  packets  orig¬ 
inating  from  a  traceroute  probe.  Three  conditions  must  be  satisfied  to  identify  a  packet  as  a 
traceroute  probe.  The  packet  must  be:  (1)  UDP,  (2)  within  the  port  range  traceroute  uses  for 
UDP  (33434  to  33534),  and  (3)  destined  for  a  protected  device  (the  web  server  in  our  experi¬ 
ments).  Once  a  packet  is  identified  as  being  part  of  a  traceroute  probe,  its  TTL  is  inspected.  The 
first  packet  in  a  traceroute  probe  will  always  arrive  at  the  intelligent  router  with  TTL=1  thus  the 
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Figure  5.2:  Topological  deceptions  must  be  consistent  across  multiple  ingress  points. 


deception  begins.  Using  the  three  conditions  for  identifying  a  UDP  packet  as  a  framework,  it  is 
trivial  to  edit  the  conditional  statements  to  identify  TCP  packets  arriving  at  port  80  and  destined 
for  the  protected  device.  The  subsequent  confirmation  of  the  packet  having  TTL=1  assures  the 
intelligent  router  that  a  TCP-based  traceroute  probe  is  incoming  and  that  it  is  time  to  deploy  the 
deception.  A  similar  process  may  be  applied  to  account  for  traceroute  probes  using  ICMP. 

5.2.7  Multiple  Ingress  Points 

The  implementation  presented  herein  is  deployed  in  a  single  border  router  for  an  AS.  Organi¬ 
zations  may  have  more  than  one  border  router.  Each  border  router  must  be  able  to  present  a 
topological  deception  that  is  consistent  with  but  not  identical  to  the  deceptive  topologies  pre¬ 
sented  by  the  other  border  routers.  Figure  5.2  illustrates  the  problem  with  routers  labeled  a  to  g. 
Recall  that  traceroute  probes  elicit  interfaces,  not  labels  as  shown  here.  The  labels  in  Figure  5.2 
are  provided  for  expediency.  Assume  adversaries  A1  and  A2  are  probing  for  node  g  and  the 
topological  deception  calls  for  a  virtual  link  between  nodes  d  and  /.  The  deception  should  be 
implemented  such  that  adversary  A1  sees  a  deceptive  route  presented  by  a  that  is  described 
as  {a,b,df,g}.  Adversary  A2  should  see  a  deceptive  route  presented  by  b  that  is  described  as 
{ b.d.f.g } .  The  two  routes  are  different  but  do  not  contradict  each  other.  Rather,  they  reinforce 
the  deception  of  a  link  existing  between  d  and/. 
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Our  vulnerability  analysis  determines  the  route  around  a  vulnerable  node  based  on  the  knowl¬ 
edge  of  only  a  single  ingress  point  to  the  network.  A  more  robust  approach  would  be  to  de¬ 
termine  a  route  around  the  most  vulnerable  node  from  any  ingress  point  into  the  network  and 
generate  tailored  kernel  configuration  files  for  each  border  router.  Such  is  not  achieved  herein 
due  to  the  existence  of  just  a  single  ingress  point  in  the  model  used  for  our  experiments. 

5.2.8  Varying  Design  Dependencies 

The  scope  for  our  implementation  is  narrow  in  that  only  a  single  protected  device  (the  web 
server)  is  defined.  A  traceroute  probe  from  outside  the  defended  network  to  the  protected  de¬ 
vice,  and  only  the  protected  device,  met  with  the  result  of  the  intelligent  router  presenting 
the  topological  deception.  An  improved  implementation  may  consider  delivering  a  believable 
deception  regardless  of  the  destination  being  probed.  Such  an  implementation  would  likely  de¬ 
termine  the  best  deceptive  route  to  present  at  the  time  the  traceroute  probe  is  received,  rather 
than  replying  with  a  pre-defined  route  prescribed  by  a  configuration  file. 

Another  design  dependency  worth  evaluating  is  the  use  of  deception  to  protect  certain  destina¬ 
tion  prefixes.  Compared  to  the  approach  described  above  which  attempts  to  account  for  every 
device  in  the  network,  it  may  be  more  appropriate  to  protect  only  those  devices  with  a  certain 
destination  prefix.  For  example,  an  organization  may  wish  to  implement  deception  to  protect 
servers  but  not  workstations  or  other  devices. 

Our  implementation  inspects  all  inbound  traffic  to  identify  a  traceroute  probe  however  it  does 
not  inspect  the  source  IP  address.  The  consequence  of  this  is  that  the  topological  deception 
is  presented  regardless  of  who  originated  the  probe.  There  may  be  some  value  in  deploying 
or  withholding  the  deception  depending  on  where  the  probe  originates.  A  set  of  known  good 
IP  addresses  may  be  spared  the  deception  while  a  set  of  known  bad  IP  addresses  may  be  pre¬ 
sented  with  the  deception.  This  would  be  especially  valuable  for  system  administrators  working 
remotely  who  may  wish  to  inspect  the  network  to  diagnose  are  resolve  network  problems. 

5.2.9  Evaluation  of  Success 

This  is  perhaps  the  most  necessary  element  left  to  future  work.  A  thorough  evaluation  of  the 
implementation’s  ability  to  deceive  a  human  user  offers  the  best  indication  that  the  methodol¬ 
ogy  and  implementation  presented  here  is  viable  and  successful.  In  a  laboratory  environment, 
human  volunteers  may  be  presented  with  a  view  into  multiple  networks  and  asked  to  deter¬ 
mine,  using  traceroute  and  other  tools,  whether  the  network  exhibits  any  unusual  behavior  or 
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attributes. 


The  success  of  our  approach  may  also  be  measured  in  the  real  world  similar  to  the  arrangement 
employed  by  Frederick.  [33].  By  placing  the  implementation  on  a  network  outside  an  AS  fire¬ 
wall  and  observing  probes  against  it,  researchers  may  see  a  decrease  in  port  scanning  against 
vulnerable  nodes  in  the  physical  network  and  an  increase  in  scanning  on  nodes  in  the  deceptive 
network. 

5.3  Adversary’s  Assessment 

Counter  to  evaluating  the  defender’s  success,  one  may  evaluate  the  adversary’s  ability  to  infer 
that  topological  deception  is  being  employed.  We  have  noted  herein  the  potential  of  issues  such 
as  packet  delay,  network  bandwidth  and  fingerprinting  to  reveal  that  deception  is  being  used. 
From  the  adversary’s  perspective,  how  valuable  are  these  points?  Can  an  analysis  of  the  delays 
between  replies  in  a  traceroute  probe  enable  the  adversary  to  deduce  the  use  of  deception?  Do 
bandwidth  limitations  in  portions  of  a  defended  network  indicate  that  deception  is  being  used? 
To  what  degree  must  an  adversary  fingerprint  a  deceptive  node  in  order  to  determine  the  actual 
nature  of  the  node?  Viewing  the  problem  space  from  the  adversary’s  perspective  is  potentially 
a  more  challenging  problem  as  an  accurate  assessment  would  require  operating  much  as  the 
adversary  would  by  using  a  set  of  intelligence-collecting  tools  and  by  operating  outside  the 
defended  network. 

5.4  Concluding  Remark 

As  the  cyber  domain  continues  to  grow  in  importance  to  military  operations  and  the  DoD  in 
particular,  the  United  States  will  need  novel  techniques  for  defending  its  networks.  Although 
the  implementation  of  topological  deception  in  this  thesis  represents  proof-of-concept  only, 
ongoing  development  of  the  research  presented  herein  may  well  complement  other  DoD  cyber 
operations  and  prove  to  be  a  useful  application  of  MILDEC  in  cyberspace. 
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